VPN connection cycling with GL-AR750S-Ext

Technical Support for Routers VPN, DNS, Leaks
1

Hi, I have this router with the March 2024 firmware and when it's working correctly it works fine. I have configured to block any non-VPN access. However, it occasionally gets into a loop where internet access is nearly impossible because the VPN connection is cycling. It's always the same pattern when this happens, a series of "bad source address" messages indicating private traffic on the glinet network is escaping NAT, then a "packet was truncated/expanded on write" message from the VPN server.

The solution seems to be repeatedly power cycling the glinet device until it stops doing this. Only one or two power cycles does not seem to be sufficient. Here is an example of one failure (after which the glinet device reconnects to VPN server).

Jun 13 03:59:51 vpnserver openvpn[3874178]: TCP connection established with [AF_INET]93.220.50.49:33666
Jun 13 03:59:51 vpnserver openvpn[3874178]: Socket flags: TCP_NODELAY=1 succeeded
Jun 13 03:59:51 vpnserver openvpn[3874178]: TCPv4_SERVER link local: (not bound)
Jun 13 03:59:51 vpnserver openvpn[3874178]: TCPv4_SERVER link remote: [AF_INET]93.220.50.49:33666
Jun 13 03:59:51 vpnserver openvpn[3874178]: 93.220.50.49:33666 TLS: Initial packet from [AF_INET]93.220.50.49:33666, sid=feb6c89a 6e8440c6
Jun 13 03:59:52 vpnserver openvpn[3874178]: 93.220.50.49:33666 VERIFY OK: depth=1, CN=Easy-RSA CA
Jun 13 03:59:52 vpnserver openvpn[3874178]: 93.220.50.49:33666 VERIFY OK: depth=0, CN=glinet
Jun 13 03:59:52 vpnserver openvpn[3874178]: 93.220.50.49:33666 peer info: IV_VER=2.5.7
Jun 13 03:59:52 vpnserver openvpn[3874178]: 93.220.50.49:33666 peer info: IV_PLAT=linux
Jun 13 03:59:52 vpnserver openvpn[3874178]: 93.220.50.49:33666 peer info: IV_PROTO=6
Jun 13 03:59:52 vpnserver openvpn[3874178]: 93.220.50.49:33666 peer info: IV_NCP=2
Jun 13 03:59:52 vpnserver openvpn[3874178]: 93.220.50.49:33666 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM
Jun 13 03:59:52 vpnserver openvpn[3874178]: 93.220.50.49:33666 peer info: IV_LZ4=1
Jun 13 03:59:52 vpnserver openvpn[3874178]: 93.220.50.49:33666 peer info: IV_LZ4v2=1
Jun 13 03:59:52 vpnserver openvpn[3874178]: 93.220.50.49:33666 peer info: IV_LZO=1
Jun 13 03:59:52 vpnserver openvpn[3874178]: 93.220.50.49:33666 peer info: IV_COMP_STUB=1
Jun 13 03:59:52 vpnserver openvpn[3874178]: 93.220.50.49:33666 peer info: IV_COMP_STUBv2=1
Jun 13 03:59:52 vpnserver openvpn[3874178]: 93.220.50.49:33666 peer info: IV_TCPNL=1
Jun 13 03:59:52 vpnserver openvpn[3874178]: 93.220.50.49:33666 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
Jun 13 03:59:52 vpnserver openvpn[3874178]: 93.220.50.49:33666 [glinet] Peer Connection Initiated with [AF_INET]93.220.50.49:33666
Jun 13 03:59:52 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 MULTI_sva: pool returned IPv4=172.16.30.5, IPv6=(Not enabled)
Jun 13 03:59:52 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 MULTI: Learn: 172.16.30.5 -> glinet/93.220.50.49:33666
Jun 13 03:59:52 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 MULTI: primary virtual IP for glinet/93.220.50.49:33666: 172.16.30.5
Jun 13 03:59:52 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 Data Channel: using negotiated cipher 'AES-256-GCM'
Jun 13 03:59:52 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 Data Channel MTU parms [ L:1552 D:1450 EF:52 EB:406 ET:0 EL:3 ]
Jun 13 03:59:52 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jun 13 03:59:52 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jun 13 03:59:52 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 SENT CONTROL [glinet]: 'PUSH_REPLY,dhcp-option DNS 10.0.0.1,register-dns,block-outside-dns,socket-flags TCP_NODELAY,route-gateway 172.16.30.1,topology subnet,ping 60,ping-restart 120,ifconfig 172.16.30.5 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)
Jun 13 04:00:07 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 MULTI: bad source address from client [192.168.8.240], packet dropped
Jun 13 04:00:10 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 MULTI: bad source address from client [192.168.8.199], packet dropped
Jun 13 04:00:11 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 MULTI: bad source address from client [192.168.8.199], packet dropped
Jun 13 04:00:11 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 MULTI: bad source address from client [192.168.8.199], packet dropped
Jun 13 04:00:12 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 MULTI: bad source address from client [192.168.8.199], packet dropped
Jun 13 04:00:16 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 MULTI: bad source address from client [192.168.8.199], packet dropped
Jun 13 04:00:19 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 MULTI: bad source address from client [192.168.8.199], packet dropped
Jun 13 04:00:22 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 TCP/UDP packet was truncated/expanded on write to [AF_INET]93.220.50.49:33666 (tried=1367,actual=862)
Jun 13 04:00:22 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 Connection reset, restarting [-1]
Jun 13 04:00:22 vpnserver openvpn[3874178]: glinet/93.220.50.49:33666 SIGUSR1[soft,connection-reset] received, client-instance restarting
Jun 13 04:00:22 vpnserver openvpn[3874178]: TCP/UDP: Closing socket

2

Hi,
This issue seems from OpenVPN client due to the routing within the OpenVPN engine.

Refer this URL to learn how to avoid this issue.

3

Are you saying this is a bug in glinet's VPN client? Why does the disconnection only occur sometimes, and other times these messages appear with no disconnection and a stable connection for hours? I'm not sure there is a connection between these messages and the packet truncated messages (which always precede a disconnection), but they are there regardless.

4

I think this issue is not GL OpenVPN client, but is official OpenVPN client, GL only integrated official app and have not rewritten its code.
As the above URL said, probably problem is OpenVPN engine, it as well as appears in another device.

5

Ok, aside from the NAT leaking problem, how can I avoid the VPN session cycling due to the disconnections? It only happens from time to time.

6

Please refer to the previous URL to learn more about it:

image
image709×651 32.3 KB

7

This answer is not helpful. I reviewed your link and I'm not interested in routing private IP traffic outside the glinet network. I care about the problem of the glinet OpenVPN client completely disconnecting ("TCP/UDP packet was truncated/expanded on write"), and then cycling again and again connecting and disconnecting in the same way, until eventually I give up, power cycle the device several times, and it begins working again. It just seems like a bug.

Does this device work reliably for anyone with this firmware? I need to force all traffic through the VPN and when the router is doing these repeated disconnections, it makes internet traffic unusable. I thought the NAT leakage prior to the disconnection indicates something is going wrong and putting the glinet VPN stack in a bad state, that's the only reason I didn't snip it.

8

Could you please add additional information about what OpenVPN server do you use?
Is there a network diagram (using draw.io) possible?

9

Please check if "OpenVPN Client Options - IP Masquerading" is on

image
image1023×312 11.2 KB

image

When the issue happens, please export a log for GL-AR750S-Ext

10

Server is OpenVPN 2.5.1 from Debian

Network diagram is
Laptop -> glinet (VPN forced) -> ISP router box (e.g. T-Mobile) -> Internet -> OpenVPN server -> Internet

At the same time I have for viewing logs:
Laptop 2 -> ISP router box -> Internet -> SSH to OpenVPN server

The second flow is never interrupted even while the first has the cycling issue. So it basically rules out all the other infrastructure components apart from glinet and OpenVPN.

IP Masquerading is always on - my configuration couldn't work otherwise because the glinet local network and remote networks of the VPN server are completely different. But that is a normal situation for a privacy VPN.

11

Please export the log and send me by PM.

12

I'm waiting for it to happen again. To be clear, exactly which log should be exported?

13

Here to export, I mainly looked into the network debug info.

image
image1335×640 70.1 KB