OpenVPN is not working if client is reconnected immediately

steamerzone

@apant Looks like the same issue I have:

https://forum.netgate.com/topic/161300/pfsense-2-5-0-openvpn-reconnect-failing

dyener

Yes, I have the same problem! It seems like the OpenVPN server (i.e. the pfSense box) does not recognize when the client has terminated the connection, and instead it waits for a ping timeout before the client is correctly understood to be disconnected. I found that the waiting period is correlated with the "Ping" settings in the OpenVPN server settings. By default "Timeout" is 60 seconds, and "ping-restart" is twice this, or 120 seconds. This is about how long it was taking before the disconnected clients could reconnect. But if I reduce "Timeout" to 20 seconds, then I only need to wait 40 seconds.

Pippin

On the client side, add:

explicit-exit-notify 3

https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html

viktor_g

feature request created:
https://redmine.pfsense.org/issues/11520

steamerzone

@pippin said in OpenVPN is not working if client is reconnected immediately:

On the client side, add:
explicit-exit-notify 3
https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html

This option doesn't seem to fix this issue, after a disconnect the client is still listed as connected in pfsense's status screen.

Edit: for this option to work it needs to have a working connection on disconnect, and most cases the reconnect is needed for a failed connection.

dyener

Thank you all for your help!

Rather than change all my config files on the client machines, I put an entry in the Advanced / Custom options in the pfSense server, push "explicit-exit-notify 3". Now I have no problem if a client manually disconnects and then reconnects immediately.

However, as steamerzone said, I am also worried what will happen if the disconnection happens inadvertently, e.g. client machine loses wifi signal or goes to sleep before the client program has a chance to send the exit signal. It should be able to regain full network functionality if it reconnects automatically in a few seconds.

Also, what is different here between OpenVPN 2.5 and previous versions? I see the explicit-exit-notify option in the 2.4 documentation, yet I don't think I had this problem with 2.4.

apant

@pippin It works like a charm ! Thanks !

@steamerzone it seems that it's normal to not work with failed connections since it's a client side option and in this case the client cannot notify the server for the disconnection.

It seems that we need a server side option here I think.

jimp

What shows up in the logs on both sides when the reconnect fails like this?

I took a test client just now and reconnected it about 20 times in a row to a UDP server without a single failure. It doesn't have exit notify enabled either.

apant

@jimp the connection is always succeed but traffic is not passing through VPN if you do not wait 2-3 minutes (without explicit-exit-notify) before reconnection. There is no error.

jimp

@apant said in OpenVPN is not working if client is reconnected immediately:

@jimp the connection is always succeed but traffic is not passing through VPN if you do not wait 2-3 minutes (without explicit-exit-notify) before reconnection. There is no error.

I was finally able to reproduce this given that bit of info and narrow it down a little:

It does appear to be related to the remote port being the same when reconnecting.
- If I set the client config to have lport 0 so it randomizes its own local port, then each reconnect can pass traffic.
- This is better behavior anyhow, I'm not sure why we don't add this into the exported configs by default.
It is not related to pf/firewall states
- Clearing the states doesn't affect whether or not the later reconnections can pass traffic when the client port is reused, so it appears to be internal in OpenVPN itself.

Still need to see if there is anything else server side that might affect it but that at least narrows the focus and identifies another potential workaround. That's assuming I'm hitting the same conditions others are, though.

Pippin

From memory, for client side it is advised to use --nobind (without --lport)
--nobind is included in NetworkManager (Linux) by default.

Will try to find the posts by OpenVPN devs...

jimp

nobind also works, likely for much the same reason.

That would be viable for remote access clients but if this same issue also affects site-to-site then that wouldn't be enough to work around it.

None of the changes in the log for OpenVPN 2.5.1 appear to be related but I'm curious if it makes a difference.

jimp

I added an issue to track the upstream problem since there isn't much we can do locally (clients in pfSense already default to lport 0)
https://redmine.pfsense.org/issues/11575

I also added an issue to have the export package automatically add nobind with an option to opt out.
https://redmine.pfsense.org/issues/11574

christian.schneider

@jimp lport 0 works perfect for me, thank you!

Pippin

This post is deleted!

Pippin

@pippin said in OpenVPN is not working if client is reconnected immediately:

Will try to find the posts by OpenVPN devs...

Please see my remark:
https://redmine.pfsense.org/issues/11575

Elrick75

@jimp Hi, I noticed that nobind or lport 0 both work but it is not possible to have both in the configuration file.
Which one should be chosen between the two please? which one is better?

Pippin

The recommendation by OpenVPN is --nobind.

jimp

Generally speaking, nobind is better.

You would only need lport 0 if you had to bind to a specific IP address on the client, but wanted a random source port. Otherwise, nobind is better since it lets to OS pick the most appropriate source IP address and port.

jeff3820

@jimp Is this change coming to the client export package or has it already been implemented?