OpenVPN is not working if client is reconnected immediately
-
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.
-
@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.
-
@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 0so 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.
- If I set the client config to have
- 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.
- It does appear to be related to the remote port being the same when reconnecting.
-
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...
-
nobindalso 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.
-
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/11575I also added an issue to have the export package automatically add
nobindwith an option to opt out.
https://redmine.pfsense.org/issues/11574 -
@jimp lport 0 works perfect for me, thank you!
-
This post is deleted! -
@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 -
@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? -
The recommendation by OpenVPN is --nobind.
-
Generally speaking,
nobindis better.You would only need
lport 0if you had to bind to a specific IP address on the client, but wanted a random source port. Otherwise,nobindis better since it lets to OS pick the most appropriate source IP address and port. -
@jimp Is this change coming to the client export package or has it already been implemented?
-
You can already get
lport 0by setting the option to randomize the local port, though I can't recall off the top of my head if that is the default. I don't think it has a way to setnobind.If it doesn't set that by default, we should probably update the package to work that way and use
nobind.
