Opened 5 years ago

Closed 19 months 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)

server.log (3.2 KB) - added by slesru 5 years ago.
client.log (4.8 KB) - added by slesru 5 years ago.

Download all attachments as: .zip

Change History (9)

Changed 5 years ago by slesru

Attachment: server.log added

Changed 5 years ago by slesru

Attachment: client.log added

comment:1 Changed 5 years ago by Eric Crist

Resolution: invalid
Status: newclosed

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.

comment:2 Changed 5 years ago by plaisthos

The up script is not run on each client connect. Only when bringing up the tun interface.

comment:3 Changed 4 years ago by slesru

Resolution: invalid
Status: closedreopened

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 4 years ago by slesru

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 4 years ago by slesru

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 Gert Döring

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 19 months ago by Gert Döring

Resolution: notabug
Status: reopenedclosed
Note: See TracTickets for help on using tickets.