VPN Policies issue

Timeslides · 2019-09-04T09:24:43.172Z

Hi all, I have a GL-AR750S running 3.026 and I’m having trouble getting VPN policies to work.

I’m using Wireguard as my VPN and the issue I have is that I any device I set to bypass the VPN (either via IP or MAC) loses internet connectivity all together. Can anyone point me in the right direction as to what the issue may be? Thanks in advance.

dzwghx · 2019-09-05T02:06:43.771Z

Can you send a screenshot of the vpn policies you set?

you can refer to the doucumentation in here

Timeslides · 2019-09-05T11:09:51.554Z

Sure, here you can see I just have my LG TV in the list but I have tried multiple other devices and all lose internet access if they are listed here.

vpnpolicy1511×1333 83.2 KB

MRizkBV · 2019-12-14T13:45:54.531Z

I am having the same issue here too. Did you find a fix?

antony500 · 2019-12-15T00:36:35.373Z

Same issue here as well, happens every time I activate VPN policies, if i disable Use VPN for all processes on the router, DNS completely stops working (but internet connection seems to work fine?). If i enable it, internet works, but everything slows down to unusable levels. This happens with both domain-based VPN policies and MAC address policies. Currently running snapshot from 20 november, 3.100

kamil · 2020-03-07T02:19:12.107Z

I have a similar issue with GL-AR750S running 3.101.

My use case is slightly different:

The GL-AR750S is connected to a VPN provider (Mullvad) with OpenVPN (UDP port 1194).
A “do not use VPN for the following” policy is added with the IP address of my private cloud server.

I attempt to connect to my cloud server with OpenVPN (UDP port 1194) from a client PC that is connected to the GL-AR750S. The connection is established successfully, but then completely freezes after 60 sec.

I’m not a Linux networking expert, but I think this may have something to do with the conntrack settings in the iptables rules that are added when the VPN Policy is enabled. The connection freezing after 60 sec seems to correlate with the netfilter conntrack UDP timeout value in “/proc/sys/net/netfilter/nf_conntrack_udp_timeout”.

root@GL-AR750S:~# cat /proc/sys/net/netfilter/nf_conntrack_udp_timeout
60

I have not tried any other VPN policies, therefore I do not know if a similar problem may exist with TCP sessions.

alzhao · 2020-03-09T10:04:01.776Z

What do you mean

kamil:

completely freezes after 60 sec.

Is it no website can be accessed? Or you private cloud server not able to be accessed?

kamil · 2020-03-10T12:59:11.314Z

The private cloud server is not able to be accessed. All other websites can be accessed and are correctly routed through the VPN provider (Mullvad).

If I turn off VPN Policy, I can connect to my private cloud server with OpenVPN and the connection is stable.

I will do some more tests and post the results.

kamil · 2020-03-10T14:20:17.183Z

The connection tracking is working, but it seems that the connmark is changing. Please see below.

root@GL-AR750S:~# cat /proc/net/nf_conntrack | grep 1194
ipv4     2 udp      17 179 src=192.168.8.219 dst=XXX.XXX.XXX.XXX sport=50781 dport=1194 packets=42 bytes=9397 src=XXX.XXX.XXX.XXX dst=192.168.20.14 sport=1194 dport=50781 packets=34 bytes=8581 [ASSURED] mark=540416 zone=0 use=2
root@GL-AR750S:~# cat /proc/net/nf_conntrack | grep 1194
ipv4     2 udp      17 179 src=192.168.8.219 dst=XXX.XXX.XXX.XXX sport=50781 dport=1194 packets=43 bytes=9501 src=XXX.XXX.XXX.XXX dst=192.168.20.14 sport=1194 dport=50781 packets=35 bytes=8653 [ASSURED] mark=16128 zone=0 use=2

Sometimes the connmark is 540416 (0x83F00) and sometimes it is 16128 (0x3F00). I suspect this means some packets are bypassing the VPN provider and some packets are not bypassing.

alzhao · 2020-03-11T04:37:53.766Z

There is a known issue that when vpn policy is turned on, the website that bypass vpn may not be accessed normally. This may be caused by CDN. Especially speedtest dot com has problems.

We are investigating this problem.

kamil · 2020-03-17T13:18:29.321Z

Thanks for the info. I’m not sure if the issue you describe is what I am seeing, because I am trying to access a server using the IP address, not domain name. However, I do understand that it may be related.

I can fix the connection issue by adding an entry to the routing table for my private cloud server. This guarantees that traffic to the server bypasses the VPN on the GL-AR750S.

root@GL-AR750S:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         *               128.0.0.0       U     0      0        0 tun0
default         192.168.20.1    0.0.0.0         UG    10     0        0 eth0.2
10.15.0.0       *               255.255.0.0     U     0      0        0 tun0
YYY.YYY.YYY.YYY 192.168.20.1    255.255.255.255 UGH   0      0        0 eth0.2
128.0.0.0       *               128.0.0.0       U     0      0        0 tun0
192.168.8.0     *               255.255.255.0   U     0      0        0 br-lan
192.168.20.0    *               255.255.255.0   U     10     0        0 eth0.2
XXX.XXX.XXX.XXX 192.168.20.1    255.255.255.255 U     0      0        0 eth0.2

The routing table shows that the default gateway for all traffic is through the VPN tunnel. Enabling the VPN Policy does not modify the routing table. Please note that the IP address of the Mullvad OpenVPN server is shown as YYY.YYY.YYY.YYY.

After I add a route entry for my private cloud server IP address (shown as XXX.XXX.XXX.XXX), my connection to the server is stable and routed correctly. All other traffic is correctly routed through Mullvad OpenVPN on the GL-AR750S.

This is only a temporary fix and needs to be configured after each power-up. If anyone has any more suggestions, I’m willing to give them a try.

robotluo · 2020-03-24T06:27:44.933Z

According to your description, I changed the DNS policy, I put the AR750S test firmware here, you can download the test.

kamil · 2020-03-26T12:29:20.365Z

Thank you. I will test it tomorrow when I have some more time and share my results.

kamil · 2020-03-31T14:25:06.770Z

I can confirm that the test firmware fixes the issue that I reported. Thank you very much.