Dual OpenVPN servers and routing

[AndrewL733]

This question is not specifically related to Asuswrt-Merlin, but it may be that the latest 386.3 release with VPN Director solves my problem. I would appreciate hearing from anybody who may know the answer to my question.

I have two Asus routers (RT-AC86U and RT-AC68U) at two homes, each running 386.2_6. The two routers are "bridged" with OpenVPN tap. The LANs on each side are on the same subnet. Each router has its own unique range for DHCP, and I'm blocking DHCP requests between the two homes, so that devices always get their IP address and gateway information from the local router. The configuration is working great. All my devices that require automatic discovery (including Apple Time Machine and security cameras and media servers) can find each other between the two homes. Every device in one house can reach every device in the other house -- bidirectionally. And simply changing my client computers to use the "gateway" on one router or the other allows me to dynamically route through either side as needed; the homes are in two different countries, and for various reasons, sometimes when I'm in one country I want my Internet traffic to appear to be originating from the other side. I'm very happy with the setup and performance. Broadcast traffic is not using a huge amount of bandwidth on the VPN -- typically less than 1 Mbps out of the 35 Mbps I get on the VPN.

Now I'm trying to add a second VPN server on the RT-AC86U side so that I can connect from outside either home and reach all IP addresses across the bridged network. I have been able to create the second VPN, and when I connect from my phone, for instance, I can reach all the devices on the RT-AC86U side. But I'm not getting successful routing to the RT-AC68U side.

Can anybody explain to me what the solution here is? And whether the 386.3 release makes this simpler to fix?

 

[eibgrad]

I assume this new OpenVPN server is *routed* (tun), NOT bridged.

Sounds like a case of the other side of the bridged tunnel NOT knowing where to correctly route the routed VPN's IP network. Once a packet is sent over the bridged tunnel, the target device on that side is probably routing it out over its own ISP gateway. Instead, you need to add a static route on that side that sends it back over the bridged tunnel and back to the other router, from whence it came. Or alternatively perhaps NAT that traffic w/ the local router's IP before its dropped on the bridged tunnel.

 

[AndrewL733]

Hi Eibgrad,

I assume this new OpenVPN server is *routed* (tun), NOT bridged.

Yes, the new server is tun, not tap

Sounds like a case of the other side of the bridged tunnel NOT knowing where to correctly route the routed VPN's IP network. Once a packet is sent over the bridged tunnel, the target device on that side is probably routing it out over its own ISP gateway. Instead, you need to add a static route on that side that sends it back over the bridged tunnel and back to the other router, from whence it came. Or alternatively perhaps NAT that traffic w/ the local router's IP before its dropped on the bridged tunnel.

I think I'm following you.

To be specific, here's the setup:

Router A (USA) 192.168.15.1
DHCP Range (USA) 192.168.15.10-192.168.15.169)
Netmask: 255.255.255.0

Router B (Europe) 192.168.15.2
DHCP Range (Europe) 192.168.15.170-192.168.15.254
Netmask: 255.255.255.0

When the TUN client connects to Router A from the outside, what route is missing? Is the problem that Router B needs a route back to the addresses being given out by the second VPN (10.16.0.0-10.16.0.254)?

 

[eibgrad]

When the routed OpenVPN client is assigned an IP on the tunnel (e.g., 10.16.0.2), and it happens that the target resides across the bridged tunnel, the target on that side does NOT know how to route it back over the bridged tunnel. So it routes it to its default gateway on the same side. Likewise, the router on that side is just as ignorant of where 10.16.0.2 came from and routes it out the ISP's gateway on that side. What you need to do is create a static route on the router @ 192.168.15.2 that points to 192.168.15.1 as the gateway to the 10.16.0.0/24 network, thus forcing replies back over the bridged tunnel.

 

[AndrewL733]

Thank you! According to your advice, on the European router I created the following static route:

To get to: Addresses: 10.16.0.0 with Netmask: 255.255.255.0 Use as gateway: 192.168.15.1 on the LAN interface.

Worked like a charm!