Opened 5 years ago
Closed 2 years ago
#1231 closed Bug / Defect (notabug)
up sript is not executed on server
Reported by: | slesru | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Generic / unclassified | Version: | OpenVPN 2.4.8 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: |
Description
Hello!
This is long standing problem.
I have 2 servers and need to add route to server routing table on client connect and remove on disconnect, so I use up and down scripts.
Sometimes up script is not called, although connection exists,
I worked around it as suggested in mailing list by using learn to add route.
But this does not work always too.
Please look what happens on server in server.log.
As you can see, server detected client connectivity problem and deleted route.
Client, at the same time, works like there was no connectivity problems, please look into client.log
I removed some lines and changes addresses.
Question here is - why client continue to work and do not try to reconnect, if server closed it's session?
Looks like bug.
Thank you!
Server version is 2.4.8 , ubuntu 16.04, compiled from sources.
Client says it is 2.4.0, but this is debian 9, so really it is patched to 2.4.6 or 2.4.7.
Attachments (2)
Change History (9)
Changed 5 years ago by
Attachment: | server.log added |
---|
Changed 5 years ago by
Attachment: | client.log added |
---|
comment:1 Changed 5 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 Changed 5 years ago by
The up script is not run on each client connect. Only when bringing up the tun interface.
comment:3 Changed 5 years ago by
Resolution: | invalid |
---|---|
Status: | closed → reopened |
Hello!
First of all this is not configuration error, this is bug.
But I provided wrong description.
Now I have more data on it.
Real problem is that server thinks that client closed connection, executes --down script , so routes are removed, but do not close connection.
Here what I see in logs:
Feb 9 08:57:46 ovpn1 ovpn-server-udp[623]: sos/83.149.37.245:25045 [UNDEF] Inactivity timeout (--ping-restart), restarting
Feb 9 08:57:46 ovpn1 ovpn-server-udp[623]: sos/83.149.37.245:25045 SIGUSR1[soft,ping-restart] received, client-instance restarting
Feb 9 08:57:46 ovpn1 openvpn: sos sudo route del -net 192.168.201.197 netmask 255.255.255.255 gw 192.168.205.1
There is nothing about this on client side, client stays connected.
As you can see server thinks client is disconnected and removes route, but really server do not close client session, because next record in log is
Feb 9 09:56:23 ovpn1 ovpn-server-udp[623]: sos/83.149.37.245:38283 TLS: soft reset sec=-1 bytes=2941705/-1 pkts=20471/0
Feb 9 09:56:25 ovpn1 ovpn-server-udp[623]: sos/83.149.37.245:38283 VERIFY OK: depth=1, C=RU, ST=Udm, L=Izhevsk, O=Belkam, OU=UIT, CN=vpn.belkam.com, emailAddress=support@…
Feb 9 09:56:25 ovpn1 ovpn-server-udp[623]: sos/83.149.37.245:38283 VERIFY OK: depth=0, C=RU, ST=Udm, L=Izhevsk, O=Belkam, CN=sos, emailAddress=support@…
If you do
kill sos
via management interface, then after keepalive timeout client restarts.
It is reproduced only on really bad links, in my case one of connections it is reproduced once per several weeks.
I looked into sources, looks like when I use kill sos, then client session is really deleted,
but when server detects ping-restart it just closes tun interface, session still exists.
Not sure about this, though.
Added following to down script:
/etc/openvpn/client-udp/disconnect.expect $common_name > /dev/null & disown
/etc/openvpn/client-udp/disconnect.expect
#!/usr/bin/expect -f
set cname [lindex $argv 0];
spawn telnet localhost 7507
expect ">INFO:OpenVPN*"
#sleep 1
send_user "kill $cname\r"
send "kill $cname\r"
expect {
"SUCCESS*" { send "exit\r" }
"ERROR*" { send "exit\r" }
}
Hope this will work.
But, I think it is better to delete client session on ping-restart.
Thank you!
comment:4 Changed 5 years ago by
After about 24 hours of testing I think that workaround works- session is always closed after server called down script and client reconnects.
Need more time for testing though...
comment:5 Changed 5 years ago by
I'd like to add that workaround works, only problem is that disconnect discovery on client takes keepalive timeout, but I do not see another way to execute up script on , let's say, client traffic...
comment:6 Changed 4 years ago by
This looks like it's not really using --server
mode on the Openvpn "Server", just --tls-server
- which is peer-2-peer mode. p2p mode does not really have a good concept of "up" and "down", because it basically assumes "peer is always there, even if not sending traffic".
In "real server" mode, it's like plaisthos said - --up
and --down
are only executed on server startup. Client connect/disconnect will call the --client-connect
script/plugin hook.
In "real server" mode, you also have --explicit-exit-notify
around to signal the client "I have kicked you out".
comment:7 Changed 2 years ago by
Resolution: | → notabug |
---|---|
Status: | reopened → closed |
This doesn't contain enough information to really identify a bug. It more looks like you might be clobbering your own routes with your learn.sh script.
We can re-open this if it proves to be a bug, but it really just looks like a configuration error. Please move to the forum or back to the mailing list.