Site-to-Site VPN Tunneling

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

David Wolfe

Occasional Visitor
Hello all,

I have two locations set up with an OpenVPN TAP interface tunnel.

Server is an RT-AC5300 running 384.19
Client is an RT-AC3100 running 386.2_4

Tried for HOURS to get routing working as a TUN interface between the two. Just couldn't get it to fly. Switched to TAP and re-IP'ed the client side to be a section of the main 192.168.1.x subnet. After a little tweaking, it's working great. All clients at both locations are now able to talk to each other without issue.

One problem I just noticed is that even though the client option for "Force Internet traffic through tunnel" is set to NO, devices on the client side are going through the VPN server for their Internet traffic. Testing with www.whatsmyip.com on a devices on the client side shows the public IP of the VPN server and not the public IP of the client router.

Anyone know what I've missed or how to get client side devices going out the client router's IP for Internet access?

Thanks

-David
 

ColinTaylor

Part of the Furniture
My initial guess would be that because you're now using a bridged connection the RT-AC3100 clients are picking up their default gateway from the DHCP server on the RT-AC5300.
 

David Wolfe

Occasional Visitor
Thanks Colin. I checked the default gateway that's being assigned to devices on the client side and it's the IP of the client side router. That was my first though as well.
 

eibgrad

Very Senior Member
Minimally, you *will* need to block DHCP across the tunnel, even if it's NOT the current cause of your problems. Because eventually it will be.

That's why a bridged tunnel (TAP) is NOT the proper solution (at least as you described the original situation). I understand you had issues w/ a routed (TUN), but you should have persisted in addressing the problem. In my experience, most ppl w/ such problems fail to realize they need to configure Manage Client-Specific Options on the server side. Without it, clients on the OpenVPN server side can NOT reach devices on the OpenVPN client side.

If problems w/ a routed tunnel persisted anyway, I'd be more inclined to either switch the roles of the two routers to see if that helped, or perhaps establishing unidirectional tunnels in each direction. But NOT a bridged tunnel.
 

David Wolfe

Occasional Visitor
Minimally, you *will* need to block DHCP across the tunnel, even if it's NOT the current cause of your problems. Because eventually it will be.

That's why a bridged tunnel (TAP) is NOT the proper solution (at least as you described the original situation). I understand you had issues w/ a routed (TUN), but you should have persisted in addressing the problem. In my experience, most ppl w/ such problems fail to realize they need to configure Manage Client-Specific Options on the server side. Without it, clients on the OpenVPN server side can NOT reach devices on the OpenVPN client side.

If problems w/ a routed tunnel persisted anyway, I'd be more inclined to either switch the roles of the two routers to see if that helped, or perhaps establishing unidirectional tunnels in each direction. But NOT a bridged tunnel.
Thanks for the input, eilgrad. I have persisted on finding a solution to the TUN interface type. However, even the most simplistic scenario of a single Windows 10 VPN client connecting to the VPN server of the router resulted in not being able to navigate to any client except the router itself. I'm certainly no network engineer but I have played with nearly all combinations of config and none of them work. So, I wasn't tremendously surprised with router to router via TUN didn't work either.

Also, PPTP and IPSec VPN servers are enabled on my router and neither of those route traffic to any target other than the router itself for even single client connections as well.

I will investigate blocking cross bridge DHCP answering though. Thank you for that advice.
 

eibgrad

Very Senior Member
Thanks for the input, eilgrad. I have persisted on finding a solution to the TUN interface type. However, even the most simplistic scenario of a single Windows 10 VPN client connecting to the VPN server of the router resulted in not being able to navigate to any client except the router itself. I'm certainly no network engineer but I have played with nearly all combinations of config and none of them work. So, I wasn't tremendously surprised with router to router via TUN didn't work either.

Also, PPTP and IPSec VPN servers are enabled on my router and neither of those route traffic to any target other than the router itself for even single client connections as well.

I will investigate blocking cross bridge DHCP answering though. Thank you for that advice.

You previously mentioned nothing about a Windows 10 client, only the ASUS AC3100. When using Windows, you have to make sure you connect the OpenVPN client (I'm assuming OpenVPN Connect) has adminstrative privileges, since adding routes to the local routing table is considered a privileged operation. When it fails, it does so silently, and is only evident in the OpenVPN log. That could explain why you can only communicate w/ the OpenVPN server itself.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top