What's new

Site-to-Site VPN Tunneling

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

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
 
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.
 
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.
 
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.
 
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.
 
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