What's new

VPN Director (Policy Rules) Problem

  • 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!

Mike S

Regular Contributor
I have two locations that I am trying to connect using the OpenVPN capabilities of Asus-Merlin. Our headquarters location has an RT-AC88U (Merlin Ver 386.7) router with an OpenVPN server configured as shown in the attached pdf. The remote location has an RT-AC68U (Merlin Ver 386.7_2) router with an OpenVPN Client configured as shown in the attached pdf.

The remote OpenVPN client is configured to use the VPN Director Policy Rules so that all traffic to our 192.168.133.0 subnet goes to our headquarters location using the VPN tunnel. All other traffic at our remote location is suppose to use the WAN service.

The VPN tunnel connects properly. We can access the internet from computers at our remote location. However, we can not access any devices on the 192.168.133.0 subnet. If I run a tracert the packets go to the remote router and then get lost.

I have also attached the routing table from the remote router. What is really strange is that the 192.168.133.0 subnet is routed to 10.135.0.2, which is NOT the address assigned to the VPN connection (which is 10.133.0.2). The 10.135.0.0 subnet is what I am using for the VPN subnet for the OpenVPN server that is configured on the remote router.

What am I doing wrong?
 

Attachments

  • ASUS Wireless Router RT-AC68U - Routing Table.pdf
    253.2 KB · Views: 67
  • ASUS Wireless Router RT-AC68U - VPN Director.pdf
    275.3 KB · Views: 68
  • ASUS Wireless Router RT-AC88U - VPN Server.pdf
    336.4 KB · Views: 64
  • ASUS Wireless Router RT-AC88U - VPN Status.pdf
    266.9 KB · Views: 59
If I turn off the OpenVPN Server at the remote router everything works fine. If I turn the remote router's OpenVPN Server back on, the problem resurfaces, apparently because the Routing Table is using the Server's VPN subnet address, rather than the VPN subnet address that is assigned to the VPN Client Connection.

This sounds like a BUG!!
 

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