Configuring Static Route to access devices from VPN (two routers)

I’m really close on finalizing my network setup but stuck on the correct Static Route config I need to do to make this work.
From my attached diagram, I need to be able to access all devices on VLAN 1 and VLAN 2 networks when accessing it from my VPN.

Internally, everything is currently working as I’d expect. With IP Passthrough enabled, My UDM gets its WAN IP from whatever my Cellular connection is at that time. I can also access the Peplink Web Admin from either the Cellular IP or the internal Untagged LAN IP, so all is good there. I can also successfully connect to my VPN, but of course I can’t, yet, access any of my end-devices.

Just not sure how/where I need to configure the static routes.

  1. Does the static route use the VPN DHCP address to the various VLAN’s? What would that generally look like?
    (There are no end-devices connected directly to the BR1, so I believe the 172 network is pretty much irrelevant)

  2. Do I configure the Static Route settings on the BR1 or my UDM, or both?

I see two key decisions that are going to cause problems for this implementation.

To answer your static route question, they go on the BR1(and on your remote VPN devices)… but then we get to problem #1.

Since the BR1 is in IP passthrough, I’m not sure that you can add a static route for and since you don’t really have an IP to assign it as a next hop. the UDM is 10.141.x.x from the cellular wan… If it would even work, it might be a manual setup each time a new IP is assigned to you.

Now problem #2… UDM Pro’s only nat on their WAN interface, They do not allow any direct routing at all unless you are ready to run ssh scripts and IPtables modifications.

If you aren’t ready to fully customize the UDMPro that way, then this architecture is a non starter.

So, we ask some key questions… What absolutely necessary function is the UDMPro doing for your network that it must be used as the NAT gateway? DHCP, Ubnt device managment, cloud key, Video recording all of that can still work, but why the NAT gateway?, DPI?.. statistics?

Are you willing to connect a VLAN from the BR1 to the LAN side of the UDMpro to allow non nat traffic to flow from the FusionHub into your network, bypassing the firewall capabilities of the UDMPro, which we showed above are not compatible with remote access via any other VPN than its own.

Hello James,
Have you spoken with your local Peplink Partner and asked if they can help you with this?

Usually, when coming in remotely via a VPN (such as IPSec or OpenVPN), you can only be assigned to a single VLAN on the FusionHub. If you set up some port forwarding at the FusionHub, then it is possible to access devices on multiple VLANs.

If possible, and we know the Peplink Switches are more expensive than the brand you have shown, use a Peplink SD Switch such as an 8 Port or 16 Port.

Happy to help,
Marcus :slight_smile:

Great info, thanks Paul

It is not absolutely necessary for the UDMPro to be used as the NAT gateway. The current config, WITHOUT VPN, this seemed to be the cleanest solution, which does work great, aside from the fact that I need to access some devices remotely :slight_smile:
I need (want) the UDMPro to at least handle DHCP, Ubnt, device management, video recording etc as you mentioned. But have no direct issues with it also being the NAT gateway.

Yes, I am open to connecting a VLAN from the BR1 to the LAN side of the UDMPro. Do you think that would then give me access to my devices? Would I then still need to proceed with static route as you first mentioned, except now I have an IP to assign as the next hop?

Hi Marcus,

I have not yet.

With that being said, I could definitely get away with having access to at least one VLAN as the main server is on VLAN 1.

I’m sure I’m missing something as I’m not familiar with Peplink switches and their functionality that differs from any other switch :slight_smile: but how does an SD Switch provide additional features for my application? Thank you!

For what it’s worth, I do currently have a 24 port switch off of the UDMPro, I just didn’t show it for simplistic sakes.

Also, I’m not opposed to this either. But, my general understanding with Static Routes is that if the LAN devices do not need to access the VPN then I don’t need a route configured on the UDMPro, and would only need a static route configured on the BR1 to be able to access networks on the UDMPro.
I would only need a device (such as my laptop) connected to the VPN, to be able to access a device on

But this still takes us back to the static route issue since I’m using IP Passthrough currently.

It isn’t just static routes, it is routing combined with NAT behavior. the UDMPro only wants traffic to go in the LAN->Wan direction… with access to the LAN only provided by port forwarding or their onboard VPN termination.

Since you are willing to forgo the UDMPro NAT routing engine, we will continue in that direction. We are going to move the NAT/routing decisions from the UDMPro to the BR1.

So, create a LAN VLAN on your UDMPro for no DHCP, assign the UDMPro, and connect the port to the BR1 in place of the WAN (remove all 172.16.4.? configurations from the WAN interface) . Switch the BR1 to regular routing mode, not Passthrough

Next, disable your UDMPro WANs and we want to put in a default route to so that all outbound traffic goes via the VLAN side to the BR1… the UDMPro will not accept a static default route on the lan side… but you can add 2 routes that add up to the complete default as documented here:

You will also need to add static routes via on the BR1 to return the and traffic back to the UDMpro.

Basic connectivity should now be restored. and we are now exposing direct access to the 10.0.?.? networks to the BR1.

To complete the fusionhub access you need to have a LAN network ( configured on the Fusion Hub… no NAT translation on either side of the PEPlink… and you should be able to ping and manage the FusionHub via its LAN IP.

The Peplink status page should show that BR1 has learned the via the pepvpn and that the FusionHub status has learned and

All that is left, is adding the static routes to your VPN client when it connects, or choosing send “all traffic” via the VPN… as from this discussion"

excellent, thank you so much Paul! I can start on some of the config but due to needing to connect to a different port physically I’ll have to wait until I go to my remote location to fix that.

But your notes all make sense, I’ll report back in a few days when I can get out there to finish the changes as I don’t want to break the current remote connection I have to the routers :slight_smile: