SpeedFusion Public IP Over Tunnels

I was reviewing[ this post] to try and forward an IP on my FusionHub to one of my MAX devices. Unfortunately, I was unable to get it to work.

I’d love the ability to take a Public IP form the FH and assign it to a SF tunnel/devcice so I don’t have to setup multiple firewalls for port forwarding and avoid double or triple NAT if I have a location that needs its own router.

You can port forward from the FH to the IP at the far end of the tunnel. You don’t forward to the MAX device, you forward on the FH to the IP and port of the actual server connected to the MAX. The MAX just routes the packet and therefore inbound traffic only has one NAT.

This assumes that you are not running any NAT in your SF tunnels.

So you can’t do it on a device by device basis… but you can do it per port.

Although with that option I am still double NATing. I would just love an IP passthough mode like they have on the BR1’s. Especially with the FH solo!

You can kind of do this if you build a L2 tunnel to the hub and have spare IPs on the same connection as the Hubs WAN.

For example, I have a FH where the WAN is sat in a /24 and can have a port connected behind remote devices L2 bridged to the FH WAN and then use addresses from that subnet quite easily this way.

<Internet> - <FH WAN> - <L2 SF Tunnel> -  <Remote Peplink> - <LAN Port configured for L2 SF> - <Device with a public IP from the FH WAN subnet>

If you want to route an actual address block down the FH tunnel you really need a balance at the concentrator end, we do this too but I cannot think of a sensible way to do with just the FH - you may be able to if you hung another router off the LAN interface of the FH I guess…

1 Like

I don’t need a block just one direct IP. So I’m theory this would work!

How should the SF profile be setup?

So, think I was misremembering how I have this setup now I’ve gone to look at the exact configuration but you can still do this with a L2 VPN it just needs a bit more config and has a few more caveats when you are using a FusionHub.

  1. FusionHub needs a second NIC adding, the LAN interface is where the FH bridges the L2 VPN traffic to, in my instance this LAN interface is connected to its own vswitch and then to a physical router, so depending on your environment where the FH is located that may make this less viable.

  2. The vNIC needs to be in promiscuous mode on VMware - not sure about other platforms, so your mileage may vary here, and may make this harder to do if you were running this in a public cloud provider (I’ve never tried that).

  3. On the hub configure a SF profile like normal, then use the hidden button to reveal the L2 profile stuff, just select the profile you want to use.

  1. On the remote end configure the SF profile like normal, but the L2 config is done on the LAN settings page where you choose a network to become part of the L2 VPN.

In most instance I set the override bridge IP to “none” as I don’t need to waste addresses from the public IP subnet for this, looking at my notes I also seem to mostly use the untagged vlan for this when doing L2 to a FusionHub and then configure a new VLAN locally which is assigned untagged to the other ports on the Balance to provide for local routing needs.

In theory if all that works once the tunnel is up a device connected to that port is basically then L2 bridged to whatever is on the end of the FH lan.

Be mindful of how you build this too - it is easy to create L2 loops at the hub end if you have things connected to the same vSwitch etc.

1 Like

All sounds doable. I maintain the ESX host so I can change the NIC config to what I need.

Will report back, I am very appreciative of this!!!

Seems not to work on a FusionHub - I am able to get the L2 to the FH but no traffic beyond the FH.

Im going to try this to see if perhaps I can have any luck!


If you want to share some screen grabs of the various config elements I’d be happy to give them the once over for you - L2 VPN on the FH is a bit fickle, but certainly works.

The vSwitch / vNic config is also important (promisc. mode is required etc.) so may be worth double checking that side of things.

A simple diagram or screenshot of the VMware network config may be helpful too to understand how things are “wired” in that sense.

1 Like

@willjones figured it out. Its a hack but it works!!!

Please share the hack…