Need help diagnosing client instability

[RVIT]

Hi there.

I've got an OVPN Access Server (2.1.9) running on AWS in multi-daemon mode (UDP and TCP), creating a Layer 3 (Routing/NAT) tunnel with about 30 unique clients configured (all on dynamic VPN IPs, using unique auto-login client configs). All internet traffic is being routed through the VPN, multiple sessions per user is enabled. While all clients are running on identical Linux-based routers with identical firmware, some of them have stable connections that will persist for days or weeks, while others seem to disconnect frequently, sometimes throwing a "disconnected because user-specific properties prevent concurrent VPN connections by this user" error. This error seems logical since each client is configured to act as a gateway to its own unique subnet, so if an immediate reconnect is attempted before the first session is closed, the server is probably detecting and preventing a routing anomaly (two clients shouldn't both be the gateway for the same subnet).

Of those clients that experience disconnects, some come back up on their own (presumably on account of some of the config parameters like ping-restart, connect-retry, etc.) while others stay disconnected until a remote user power cycles their device. When I'm working on a client experiencing disconnects, I notice that my SSH session will terminate and the VPN session will still show as active for about 2.5 minutes before the server closes the connection. In some cases, I can observe a new session being initiated by the disconnected client very quickly thereafter. Others will not come back up without a reset done remotely.

My access server is configured with the following additional directives:

Code: Select all

cipher AES-128-CBC
keepalive 15 75
resolv-retry infinite
persist-tun
persist-key
duplicate-cn

The following additional client directives are also specified:

Code: Select all

cipher AES-128-CBC
keepalive 15 75
resolv-retry infinite
persist-tun
persist-key
connect-retry 60
connect-timeout 60
connect-retry-max infinite

The client config file looks like this (certs removed):

Code: Select all

setenv FORWARD_COMPATIBLE 1
client
server-poll-timeout 4
nobind
remote [URL to OVPN server removed] 1194 udp
remote [URL to OVPN server removed] 1194 udp
remote [URL to OVPN server removed] 443 tcp
remote [URL to OVPN server removed] 1194 udp
remote [URL to OVPN server removed] 1194 udp
remote [URL to OVPN server removed] 1194 udp
remote [URL to OVPN server removed] 1194 udp
remote [URL to OVPN server removed] 1194 udp
dev tun
dev-type tun
ns-cert-type server
reneg-sec 604800
sndbuf 100000
rcvbuf 100000
comp-lzo no
verb 3
setenv PUSH_PEER_INFO

(….and then additional directives at the end of the file...)

Code: Select all

cipher AES-128-CBC
keepalive 15 75
resolv-retry infinite
persist-tun
persist-key
connect-retry 60
connect-timeout 60
connect-retry-max infinite
daemon

From the router logs, here is the PUSH string received by the clients:

Code: Select all

PUSH: Received control message: 'PUSH_REPLY,explicit-exit-notify,topology subnet,route-delay 5 30,dhcp-pre-release,dhcp-renew,dhcp-release,route-metric 101,ping 15,ping-restart 75,comp-lzo yes,redirect-gateway def1,redirect-gateway bypass-dhcp,redirect-gateway autolocal,route-gateway [VPN subnet removed].145,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,register-dns,block-ipv6,ifconfig [VPN subnet removed].151 255.255.255.240'

Is there something in the way I've configured things that is leading to certain clients experiencing disconnect issues (and/or problems auto-reconnecting)? I've been over every router setting and can't find any discrepancies between a client whose connection persists and one whose connection drops frequently. Any insight is appreciated.

[cbm64]

Hi there,

I've almost an identical setup running 2.5.2 on AWS. Some clients are stable for days and weeks, other tend to drop and have the same "disconnected because user-specific properties prevent concurrent VPN connections by this user" in the server log every 1.5 minute or so. All clients connect using 4G/LTE routers. I'm pulling hairs.

Did you solve this one?

Thanks,
Martijn

[novaflash]

I'd suggest reading the client side log file very carefully to see what is going on with the connection dropping like that.

Also, that message is pretty normal when a connection dies and tries to re-establish. Usually the client is the first to give up and retry, the server is a little more forgiving and the session lingers a bit longer there.

[cbm64]

Indeed. Problem is that this station is in the field and I cannot reach it remotely. Have a lot of exactly the same hardware with same setups (automated provisioning), but with different keys. I think I need to have a field trip soon.

[novaflash]

Don't you have one of those devices locally you can mess with to see if you can reproduce the problem?