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.
