Can't access LAN or FusionHub web interface FROM LAN


#1

Hello – I’m no networking expert but feel like I should know enough to get this working but I’m stuck. I have a number of web servers on a remote LAN with a PFsense VM that I use mostly for VPN access. It looks basically like this on the LAN side:

10.0.0.1 - pfsense
10.0.0.2 - vmware vcenter
10.0.0.3 - vmware vcenter appliance
10.0.0.46 - FUSIONHUB
10.0.0.48 - web server
10.0.0.49 - web server
10.0.0.50 - web server

(1) First of all, it seems odd that I can’t VPN into the PFsense and then access the web interface for FusionHub IP. I have no issues accessing web interfaces on the web servers via the LAN. I can only access the web interface via public IP.

(2) I can access (a) FusionHub interface via LAN IP over PepVPN and (b) one web server after I added a route on that server back to my MAX700.

(3) Cannot access any other VM on the LAN over PepVPN (I have not added routes to each of them but I did try to add route to PFSense)

I do see on my MAX700 that PepVPN knows that 10.0.0.0/24 is my remote peer. I cannot ping anything except for FUSIONHUB and the 1 web server that I added the static route to.

I have tried all sorts of combinations of NAT and “route pepvpn traffic to LAN” and such but can’t quite understand why this isn’t working.

At a very basic level I am baffled why I can’t see the FusionHub web interface at 10.0.0.46 when I am connected via my PFSense VPN. Maybe it would be good to start here on troubleshooting. Any help would be appreciated.


#2

(1) First of all, it seems odd that I can’t VPN into the PFsense and then access the web interface for FusionHub IP. I have no issues accessing web interfaces on the web servers via the LAN. I can only access the web interface via public IP.

The LAN side of the FusionHub does not have a default route, so I suspect your VPN connection into the PFsense box is a Layer 3 VPN and as such the FH LAN interface doesn’t have a route back to your remote subnet - it will instead be sending replies out via its own WAN interface.

(2) I can access (a) FusionHub interface via LAN IP over PepVPN and (b) one web server after I added a route on that server back to my MAX700.

That makes sense, the Webserver would need a static route to know to divert traffic for your remote subnet (on the MAX 700) to the IP of the Fusionhub as the next hop / Gateway.

(3) Cannot access any other VM on the LAN over PepVPN (I have not added routes to each of them but I did try to add route to PFSense)

Assuming the PFsense is the gateway for the LAN segment then this should work fine so long as ‘route all traffic to LAN’ is set on the Fusionhub and you add the PFsense as its LAN gateway .


#3

When I enable “route all traffic to lan” with gateway as 10.0.0.1 (pfsense) I lose access to everything (internet and LAN). Well the only thing I can still access via internet IP is the web interface for remote FusionHub.


#4

That’s because your PFsense needs a static route for the remote LAN Subnet on the MAX 700 with the FusionHub as the gateway so it knows how to route back to it.


#5

I added that route in PFsense before but it doesn’t seem to have any effect. I don’t know much about layer 2 vs 3 and all that but it seems like if I set the option for the web interface to be accessible via LAN and WAN… why wouldn’t it show up via LAN IP? You lost me there. I use webmin and phpmyadmin for mysql and other web admin interfaces on several servers on this LAN via PFsense vpn and there is no problem. Why would there be with this FusionHub?


#6

The reason Fusionhub is not behaving like anything else you’ve got there is because of the way it manages routing. It was originally designed to have a single WAN interface (no LAN at all) as a PePVPN concentrator. So you would take a remote peplink device with multiple WANs (fixed lines and cellular for failover perhaps or multiple cellular for bandwidth aggregation) and the traffic would come from your remote Peplink in via the WAN of the Fusionhub and then go back out via the same WAN again so that your remote sites could access the internet with high reliability and bandwidth aggregation using multiple WAN links.

Then the option of a LAN network was added so that the Fusionhub could sit in a public cloud and give the users on the LAN of the remote Peplink device highly available high bandwidth access to servers in private LAN segments in the cloud.

Then there was a demand to be able to route traffic from remote Peplink devices over PepVPN/SpeedFusion via the FusionHub onwards to existing corporate gateways and firewalls sat alongside the FusionHub with specific web filtering and auditing capabilities for compliance purposes and that’s when the ‘Route all traffic to LAN’ feature was added.

So what I’m saying is, FusionHub is a Router not a server and there are different topologies it supports but you need to recognise which one you need and then configure it to work in that topology.

From your OP it sounds like you have this topology:


In this topology freshly deployed, clients connected to the MAX 700 can only access the LAN of the FusionHub and the internet via the FusionHub.

Reason: They can not access the LAN interfaces of the PFsense box or the webserver because neither of those devices know how to route traffic back to the remote 192.168.50.0/24 LAN.

Fix: To make this work you do one of two things. You either set the PepVPN to NAT mode in which case traffic coming from the LAN clients of the MAX 700 is NATTED by the Fusionhub so that the PFsense and webserver see it as originating from the FusionHub LAN IP (10.0.0.46) which they do know how to reply to instead of 192.168.50.1. OR you add a static route on the PFsense for the 192.168.50.0/24 network with a gateway of 10.0.0.46 so that when the webserver goes to reply to 192.168.50.1 and sends its response to the PFsense server as its default gateway (because its not a local subnet) , the PFsense server knows how to reply and where to forward the traffic to.

So lets assume you set a static route on your PFsense. When you connect via VPN to your PFsense box you still won’t be able to access the FusionHub webui on the LAN - why? Because when your traffic hits the Fusionhub the reply subnet is the remote 172.16.1.0/24 network. Fusionhub doesn’t have a route for that network so sends the response out over its default route - which is its internet facing WAN.

At the time of writing there is only one way to get the FusionHub to send the traffic back over the LAN and that is to send all outbound traffic via the LAN instead of the WAN and set the gateway IP as the PFsense box which does know how to route traffic back to the 172.16.1.1 network.

In the next version of FusionHub which is in beta now I think, you can add static routes to the Fusionhub which solves this. So a static route on the Fusionhub for the 172.16.1.0/24 network with a gateway of 10.0.0.1.

Hope that helps.


#7

Thanks for the detailed reply. I am going to try to reinstall the whole thing right now. I’ve already blown away my old VM and am redeploying now. I don’t trust the second NIC that I added after setting up FusionHub for the first time so just to rule that out.

I swear I tried every combination of NAT and “route all to lan” and couldn’t get anything to work. Also, I believe that I did setup the static routing on PFsense as you describe and couldn’t get that working. I’ll keep at it and will report back if I figure out my issue.

Since I was able to get a single server working properly by adding a static route then maybe the issue really is with my PFsense static route. Perhaps I need to reload the routing table or something that I missed.


#8

OK I started from scratch, installed fresh FusionHub, upgraded to BETA, and I seem to have this working via NAT. I hate to do a NAT unless absolutely necessary but it is working for my needs at the moment so I am going to leave it alone for awhile so I can get some other things done.

To summarize:
– using BETA 6.3.2s004 build 1427
– set static route to the 10.0.0.0/24 LAN with 10.0.0.1 as gateway (unsure if this is needed – seems like route could be automatic)
– route is set in my PFSense back to MAX700 (unsure if needed)
– “route all to LAN” enabled
– DHCP for NAT mode profile enabled
– new private IP range set for above DHCP
– NAT remote connection in this section is enabled
– NAT mode enabled under PepVPN profile

Basically I just enabled EVERYTHING and it seems to work now. What is confusing about all of this is that I have to look in a bunch of places to make it work. Also the descriptions seem like they could be better for the options. This whole second DHCP server is quite confusing as I have no idea why it is needed… is it giving an IP from this to each device that is coming in to FusionHub, so in my case just one for my MAX700? Or is each client on my MAX700 getting a local DHCP IP and then mapped to one from his PepVPN range?

And then I sure have ticked off a lot of options with NAT in the description. Under WAN there is NAT mode enabled, and then under the Speedfusion profile NAT mode is selected… and I don’t understand what is different about that option and the “NAT remote connection” option under “DHCP Server for NAT mode profile” section. I think it might be that ticking “NAT mode” under the SF profile basically just enables the options in this “DHCP Server for NAT mode” module? If that is the case, I would recommend that the developers change the title for that module to “Options for Profiles Using NAT Mode” or something. I don’t think DHCP should be in the module title because there is a NAT option in that box, and putting DHCP in the module title is kind of extraneous when you could try to help the user better understand that this stuff applies to the profiles that have NAT Mode enabled.

Question: why is the “NAT remote connection” option needed and not just assumed? Are there cases when a user would enable NAT mode and not the option to NAT remote connection?


#9

Question: why is the “NAT remote connection” option needed and not just assumed?

“NAT Remote Connection” is needed in your topology because you didn’t add a static route on your PFsense for the remote MAX 700 LAN subnet with the FusionHub as the gateway). Without that static route your devices in the 10.0.0.0/24 LAN wouldn’t know how to route back to the MAX LAN via the Fusionhub. Its not assumed because NAT is not always needed or desired.

With “NAT Remote Connection” enabled, traffic from your MAX 700 passes through NAT with the LAN IP of the FusionHub as the source - your webservers know how to return traffic there since it is on the same subnet.

Are there cases when a user would enable NAT mode and not the option to NAT remote connection?

Yes, when the DHCP Server for the NAT Mode Profile is dishing out IP addresses that are routable on the local LAN segment, so if you assigned a range in your 10.0.0.0/24 subnet here (like 10.0.0.50-60) you would not need to then enable NAT Remote Connection, or if you assigned a brand new range (like 192.168.11.1-254) and then added a static route to your PFsense for that subnet with the LAN IP of the FusionHub as the gateway.


#10

Thanks Martin. That helps quite a bit. I like the option of giving out a separate DHCP range for SF so I may try that. So I would LEAVE “NAT Mode” enabled under the profile but NOT tick and enable “NAT Remote Connection” option under “DHCP Server for NAT mode profile” ?

I think that is what you are saying – but see how confusing that it? Using NAT mode but not NAT’ing?


#11

I think that is what you are saying – but see how confusing that it? Using NAT mode but not NAT’ing?

Ha. Nothing’s confusing once you understand it. :slight_smile:

Not sure I can think of a better way for it to be explained or for Peplink to identify the option, and the little blue question marks in the UI do an excellent job of explaining the purpose. Those blue question marks are always your friend - as well as the FusionHub manual of course :wink:


#12

LOL I agree… it’s all becoming so much more clear.

But the little blue dot to enable NAT MODE under profile says “By selecting this option, the remote unit VPN will be assigned with an IP address from the local DHCP server. All the remote side traffic via this VPN will go through Network Address Translation (NAT) using the assigned IP address.”

But that isn’t true, is it? The NAT option is actually controlled under “DHCP Server For NAT Mode Profile” where you can disable it, correct?

Basically the only thing NAT MODE option does is enable the profile to use options under “DHCP Server For NAT Mode Profile” ?

If you enable NAT MODE but disable both the DHPC server and NAT under there, does NAT MODE do anything at all?


#13

Hi,
The description in the help text is correct. You can enable/disable NAT mode for each SpeedFusion profile.
You must enable DHCP server if at least one of the SpeedFusoin profile is using NAT mode or otherwise the profile cannot establish.


#14

But if you enable NAT Mode – AND – disable NAT under “DHCP Server For NAT Mode Profile” – then is there any NAT happening? If no, then my opinion is that NAT Mode should have a name that does not include NAT. Otherwise it is confusing to new users. If I understand correctly, if you disable NAT under that “DHCP Server For NAT Mode Profile” module, then NO profiles will use NAT for NAT mode, correct?


#15

Got your point, we will enhance that to avoid confusion.


#16

Maybe some changes like this would be more clear…

“DHCP Server For NAT Mode Profile” module title ==> “Master NAT/DHCP Settings for Profiles”
“NAT Mode” checkbox ==> “Use Master NAT/DHCP Settings”