Conflict with Policy Rules in OVPN

[marelit]

Hello,

I have currently set up the following:
​

RT-AC56U 380.68_4                                   RT-AC66U 380.69
192.168.4.1                     <--- (tun)          192.168.3.1
(OVPN Server)                                       (OVPN Client)

Push LAN to clients (x)                             Create NAT on tunnel (x)
Direct clients to redirect Internet traffic ( )     Accept DNS Configuration (Strict)
Respond to DNS (x)                                  Redirect Internet traffic (No)
Advertise DNS to clients (x)                                     
Manage Client-Specific Options (x)
Allow Client <-> Client (x)

Client and router are set up at two different locations and every device in 192.168.3.* should be able to ping every device in 192.168.4.* and vice versa. Internet traffic should not be redirected. I managed to achieve this through this guide: https://openvpn.net/index.php/open-source/documentation/howto.html#scope
Everything worked perfectly.

Now my goal was to have one device x from the client network (192.168.3.x) to additionally route all the Internet traffic through the tunnel.
So I changed "Redirect Internet traffic" to "Policy Rules (strict)" and "Block routed clients if tunnel goes down" to "Yes".
I added 192.168.3.x to the list, chose 0.0.0.0 as destination IP and for the Interface VPN.
If I now apply the configuration, the device x routes all the traffic through the tunnel as expected, but I am not able to ping any devices in 192.168.3.* from 192.168.4.* anymore. If I revert the changes, I am able to ping as before, but then of course device x' Internet traffic won't go through the tunnel.

Could someone point me in the right direction to get both things working at the same time?

I would really appreciate any advice, thank you.​

 

[Jack Yaz]

Does it work with policy rules, non-strict?

 

[marelit]

No, unfortunately it does not work with either of the two Policy Rules settings.

Maybe I should mention that if I connect to the OVPN Server (192.168.4.1) with another device, then I am able to access the 192.168.3. subnet from that device (probably because of Allow Client <-> Client (x)).

EDIT I have the parameter "username-as-common-name" in the server config in order to distinguish between clients

 

[marelit]

I left the Policy Rules changed to non-strict now as Jack suggested.

I found out a few new things.
So as I mentioned I am not able to ping any device on the client side (192.168.3.*) from the Server LAN as soon as I turn on Policy Rules - EXCEPT for the device x that should be routed through the VPN tunnel.
According to my knowledge this would mean that the Server config is perfectly fine. So the client config must be the issue.
Enabling Policy Rules probably not only redirects the specified device x through the tunnel, but also blocks all the other devices in the client network from accessing the tunnel at all such that even non-Internet traffic cannot pass through the tunnel.

I tried to read up on the whole topic in https://www.snbforums.com/threads/selective-routing-with-asuswrt-merlin.9311/ but I could not really grasp the whole topic. It would be great if someone who is more experienced than I am like @Martineau could help me out.

Thank you!

 

[Martineau]

I left the Policy Rules changed to non-strict now as Jack suggested.

So as I mentioned I am not able to ping any device on the client side (192.168.3.*) from the Server LAN as soon as I turn on Policy Rules - EXCEPT for the device x that should be routed through the VPN tunnel.

I tried to read up on the whole topic in https://www.snbforums.com/threads/selective-routing-with-asuswrt-merlin.9311/ but I could not really grasp the whole topic. It would be great if someone with much more experience like @Martineau could help me out.

You could try adding an additional Selective Routing rule on the Client:

So I have defined a single device (my Nexus-7) on the client LAN to always use the VPN, but there is also the additional RPDB rule that explicitly includes the remote server LAN via the tunnel.

My test (using VPN Client 4) shows no interruption in the ability to PING from the server (or vice-versa)

RT-AC56U Site A Glenside (Server)          <<-----         RT-AC68U Site B Martineau (Client)
Firmware v380.66_6                                         Firmware v384.3 Alpha2
10.99.8.0/24                                               10.88.8.0/24

                                                           Redirect Internet traffic=Policy Rules (Strict)

admin@RT-AC56U:/jffs/scripts# ip rule                      admin@RT-AC68U:/jffs/scripts# ip rule

0: from all lookup local                                   0: from all lookup local
32766: from all lookup main                                10700: from all fwmark 0x4000/0x4000 lookup Glenside
32767: from all lookup default                             10701: from 10.88.8.155 lookup Glenside
                                                           10702: from all to 10.99.8.0/24 lookup Glenside
                                                           32766: from all lookup main
                                                           32767: from all lookup default

NAS DS-212J (10.99.8.196)                                  NAS DS-416 (10.88.8.197)
                
admin@RT-AC56U:/jffs/scripts# ping ds-416                  admin@RT-AC68U:/jffs/scripts# ping 10.99.8.196

PING ds-416 (10.88.8.197): 56 data bytes                   PING 10.99.8.196 (10.99.8.196): 56 data bytes
64 bytes from 10.88.8.197: seq=0 ttl=63 time=26.894 ms     64 bytes from 10.99.8.196: seq=0 ttl=63 time=26.505 ms
64 bytes from 10.88.8.197: seq=1 ttl=63 time=26.817 ms     64 bytes from 10.99.8.196: seq=1 ttl=63 time=25.778 ms
64 bytes from 10.88.8.197: seq=2 ttl=63 time=27.014 ms     64 bytes from 10.99.8.196: seq=2 ttl=63 time=26.276 ms
64 bytes from 10.88.8.197: seq=3 ttl=63 time=27.065 ms     64 bytes from 10.99.8.196: seq=3 ttl=63 time=29.444 ms
--- ds-416 ping statistics ---                             --- 10.99.8.196 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss  4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 26.817/26.947/27.065 ms           round-trip min/avg/max = 25.778/27.000/29.444 ms

NOTE: Apart from our servers (RT-AC56U) being identical, the firmwares are not, so YMMV.

 

[marelit]

For whatever reason the simple solution to just add another rule for my remote LAN never crossed my mind. Probably because it was working before without the rule, when I had Policy Rules still turned off.
At first, after adding the rule and changing Policy Rules to strict, nothing seemed to happen at all... but as always a reboot of the client router did the trick!

Thank you so much Martineau for the detailed solution!