OpenVPN client frequently change tunnel IP address
I have problem with client who frequently change tunnel IP address, and his bounded services, which got disconnected all the time.
IP address of tunnel network changes, and always to same address ie. if IP is x.x.x.18 it changes to x.x.x.24
In logs I see that openvpn throws:
TLS ERROR: received control packet with stale session;
TLS ERROR: TLS key negotiation failed to occur within 60 seconds;
TLS ERROR: TLS handshake failed
and after that this:
Server poll timeout, restarting;
SIGUSR1[soft,server_poll] received, process restarting;
NOTE: the current --script-security setting may allow this configuration to call user-defined scripts;
Preserving previous TUN/TAP instance: ovpns2;
UDPv4 link local (bound): [AF_INET] "WAN IP-ADDRESS";
UDPv4 link remote: [AF_UNSPEC]
Does anyone know how I can solve this ?
Anyone knows something ?
Site to site VPN ?
I'd say it's their issue not yours.
Gertjan last edited by Gertjan
Really don't know why or what happens, but I have questions.
@dzonic90 said in OpenVPN client frequently change tunnel IP address:
if IP is x.x.x.18 it changes to x.x.x.24
is not really a problem. The client needs an IP to connect to ..... whatever he connects to.
The real question is, I guess, why is your connection going down.
Invite this "client" at your place, and have it him connected (put a switch on the WAN side - so he faces WAN directly or something like that - or connect to the VPN Server from LAN).
Does he get disconnected or do you see the same TLS errors ?
Now, send him down the road, let him knock on the door of some guy living there so he has an Internet connection from there.
Let him connect again ....
Do the same test.
Now, if needed, send him to the other side of the city.
Same test ....
The state ?
As you might know, VPN uses UDP. These packets can arrive, or not. If a packet gets lost up on the road, the entire TLS encoded stream blows up - remember : this is UDP, not TCP. The channel "VPN server <-> client" has to renegotiate on new TLS key pair, which, in your case, doesn't even work out : the connection is bad .....
Your client is using 3G/4G or other radio connection ? A very small network outage will disrupt the connection.
The IP question is something else.
Normally, the internal DHCP server build into the VPN server will give the same IP to the same device when it comes back. Mine does.
Mine internal DHCP doesn't.
It always give different.
Pippin last edited by
Normally, the internal DHCP server build into the VPN server will give the same IP to the same device when it comes back.
If the client tries to reconnect within the default --keepalive 10 60 setting, then the server gives a different tunnel IP. This is because the server doesn't know the client has lost it's connection. It can take up to 120 seconds before the server realizes/assumes that the client is gone.
Even if the client is assigned a static tunnel IP based on it's certificate CommonName through Client Specific Overides. It is no guarantee the client gets the same IP. Even not with --ifconfig-pool-persist ips.txt
The following is the only way to assure the client gets the same IP:
server 10.0.8.0 255.255.255.0 'nopool' ifconfig-pool 10.0.8.101 10.0.8.253
In this example 10.0.8.2 till 10.0.8.100 can be used for static assignment, 10.0.8.101 till 10.0.8.253 for dynamic assignment.