Computer Switching to VPN Despite "Routing Policy" setup

[fff]

FreshTomato Firmware 2023.2 K26ARM USB AIO-64K on Netgear R7000

Used / Total NVRAM : 52.96 KB / 64.00 KB (82.75%)

‌

Hi,

Sorry to post here, but I already ask for help on linksysinfo, and reddit, but I didn't have answer.

Don't know if it is a bug, a known issue or a mistake I made.

Don’t know either if it is a “major” issue, but I can’t use my vpn…

I have a desktop computer at 192.168.2.101 and a Raspberry PI that I use for my torrent downloads at 192.168.2.165.

I'm using NordVPN. In the "routing policy" section of the "OpenVPN Client Configuration," I've specified my Raspberry PI's IP (192.168.2.165) as a "source IP".

I tested the detected outgoing IP with torguard.net, and it's indeed the VPN's IP, not my real IP. My desktop computer remains on my ISP's IP.

However, shortly after starting the VPN, my desktop computer switches to the VPN, even though it shouldn't. (The PI remains on the VPN all the time without issue.)

I stop and restart the VPN, and everything goes back to normal (desktop computer without VPN, and PI on VPN).

And five minutes later, it happens again...

I looked at my log, and nothing is written when my computer switch to vpn...

Thank you in advance.

‌

‌

‌

‌

[fff]

When Vpn is activated:

iptables -t nat -nvL

I can see this line is added, seems legit, and nothing change when vpn is bugged :

Code:

   51  7079 MASQUERADE  all  --  *      tun11   0.0.0.0/0            0.0.0.0/0

‌

‌

And

iptables -nvL FORWARD

When OFF

Code:

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0

‌

‌

‌

When ON

Code:

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0
   12  1959 ACCEPT     all  --  *      tun11   0.0.0.0/0            0.0.0.0/0
    0     0 DROP       all  --  tun11  *       0.0.0.0/0            0.0.0.0/0            state

‌

‌

Nothing different when bugged

---

But I have this 2 lines when On:

Code:

   0     0 REJECT     all  --  *      vlan2   0.0.0.0/0            23.75.3.237
   0     0 REJECT     all  --  *      !tun11  0.0.0.0/0            23.75.3.237

‌

‌

When vpn is bugged:

Code:

   0     0 REJECT     all  --  *      vlan2   0.0.0.0/0            104.74.109.137
   0     0 REJECT     all  --  *      !tun11  0.0.0.0/0            104.74.109.137

‌

‌

‌

I tested it again, and I have :

Code:

   0     0 REJECT     all  --  *      vlan2   0.0.0.0/0            23.75.3.237
   0     0 REJECT     all  --  *      !tun11  0.0.0.0/0            23.75.3.237

‌

‌

and when bugged :

Code:

   0     0 REJECT     all  --  *      vlan2   0.0.0.0/0            104.84.95.135
   0     0 REJECT     all  --  *      !tun11  0.0.0.0/0            104.84.95.135

‌

‌

‌

But, I still don't know how to interpret that....

[pedro]

I’ve been using Routing Policy for years (with Kill Switch), and I can tell you - it’s rock solid.

If I were you, I'd look for a problem in your network configuration.

‌

BTW:

• instead of ‘auth sha512’ use: Basic → Auth digest → SHA512
• instead of ‘remote-cert-tls server’ use: Advanced → Verify Certificate (remote-cert-tls server)
• ‘persist-key’ and ‘persist-tun’ are already in generated client config, so no need to add them to custom config
• instead of ‘reneg-sec’ 0 use: Advanced → “TLS Renegotiation Time” → 0
• why are you using ‘remote-random’ if you don’t use 'remote host1 port proto', 'remote host2 port proto', etc (well, these may be pushed from server, right)?
• why ‘nobind’?

One more: your desktop computer at 192.168.2.101 will use VPN for every connection defined in Routing Policy “To Domain”.

[fff]

I think I found the problem.

Hopefully, this will help someone avoid making the same mistake.

In the OpenVPN Client Configuration under Routing Policy, if "To domain" is selected with an input starting with "http://" or "https://" instead of just "anydomain.com", the bug will reappear after 3 minutes.

For your information, I tested multiple options and found that "http" and "http:" don't cause any issues, but when "http://" and "htpp://anything" are used, the bug comes back. (same for https)

It was my mistake, but I think that at least a warning line should be added to the informative text.

Thanks

BTW : I removed from script and used options instead as you suggest.

about ‘remote-random’ and ‘nobind’, I used a tutorial, without knowing exactly what every option means… (Bad Boy…) But It still works without this option.

Thanks again

‌

[pedro]

GUI: VPN Tunneling: OpenVPN Client: Routing Policy: add more thorough domain validation (resolves #285)

→ <<cset d8556264dad1>>