Bug #1025
closed
OpenVPN in client mode requires local port set for multiple instances
Added by Jim Pingle about 14 years ago.
Updated almost 14 years ago.
Description
If you create an OpenVPN client, the local port is left blank, and it will automatically use 1194
If you create a second client instance and leave the field blank, it will also try to bind to 1194, and fail.
Whichever instance happens to start last will not function:
Nov 18 19:23:28 openvpn[22341]: UDPv4 link local (bound): [AF_INET]192.168.197.153:1194
[...]
Nov 18 19:24:03 openvpn[33190]: TCP/UDP: Socket bind failed on local address [AF_INET]192.168.197.153:1194: Address already in use
So we need some way to either find a free port or, if possible, make the client pick a random source port insetad.
it ought to just default to using a random port
Is there a directive that indicates that in the config file? Mine are fighting for 1194 unless I hardcode.
I thought it was using a random port also, but I checked on my firewalls with multiple existing clients and I'd hardcoded the ports on all of them.
Hi Jim,
Yes, the directive is "local_port" in config.xml:
<openvpn>
<openvpn-client>
<vpnid>2</vpnid>
<protocol>UDP</protocol>
<dev_mode>tun</dev_mode>
<ipaddr/>
<interface>any</interface>
<local_port>7823</local_port>
It is mapped to "lport" in the openvpn config file.
Pierre
Yes I know that. When you do not specify a local port, it's still trying to take 1194 even though there is no config directive to do so (no lport in the conf file). I was asking if there was a config directive to ensure a random local port.
I'll have to give that one a try. We are on the devel version of openvpn, current number is 201019, which according to the file dates in the tgz is from May, and I see that line in options.c.
So it may be as easy as assuming 0 for the value of lport unless otherwise specified. I'll run some tests tomorrow.
Thanks for looking that up.
This made me notice a related regression from 1.2.x, you can specify a dynamic source port and it just adds "nobind" to the config rather than lport. The client config in 1.2.x has "Dynamic sourceport", that needs to be brought back and ensure it's properly upgraded from existing configs or it'll break some upgraded configurations with port conflicts.
I'd have to check the config docs again but I think that if you specify a listening interface you have to use lport. We may have to just use lport 0 in place of the old dynamic source port option. The change was probably made because you can choose the interface in the GUI now, the old option may only work if you choose interface=any.
Confirmed, lport 0 does make clients use a random source port.
- Status changed from New to Feedback
- % Done changed from 0 to 100
Also confirmed that nobind only works if you do not choose an interface, so the old "dynamic sourceport" checkbox isn't needed, and is now the default. I suppose we could add some upgrade code that assumes 1194 if dynamic source is unchecked and local_port is empty in the config, but it seems like it may be asking for trouble.
I combined the test for using nobind and the lport setting in e39243843f16d4c8908bf0726e68e65887774f0d to avoid a situation where the commit I did initially may have used lport 0 and nobind at the same time, which isn't valid.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF