Cannot start 3rd openvpn instance unless 'nobind'

[mmokrejs]

Hi,

interestingly I have two openvpns running (as a client) with same settings, so using 'bind' mode. I could not get started a third cleint connection concurrently, I had to shutdown either of the two previous client connections. The error message I was receiving was:

Sep 21 20:08:52 vostro openvpn[12392]: Control Channel MTU parms [ L:9122 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Sep 21 20:08:52 vostro openvpn[12392]: GETADDRINFO flags=0x0901 ai_family=0 ai_socktype=2
Sep 21 20:08:52 vostro openvpn[12392]: RESOLVE_REMOTE flags=0x0901 phase=1 rrs=0 sig=-1 status=0
Sep 21 20:08:52 vostro openvpn[12392]: Data Channel MTU parms [ L:9122 D:9122 EF:122 EB:1656 ET:0 EL:3 AF:3/1 ]
Sep 21 20:08:52 vostro openvpn[12392]: crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by 40 bytes
Sep 21 20:08:52 vostro openvpn[12392]: calc_options_string_link_mtu: link-mtu 9122 -> 9042
Sep 21 20:08:52 vostro openvpn[12392]: crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by 40 bytes
Sep 21 20:08:52 vostro openvpn[12392]: calc_options_string_link_mtu: link-mtu 9122 -> 9042
Sep 21 20:08:52 vostro openvpn[12392]: Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 9042,tun-mtu 9000,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Sep 21 20:08:52 vostro openvpn[12392]: Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 9042,tun-mtu 9000,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Sep 21 20:08:52 vostro openvpn[12392]: TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:1194
Sep 21 20:08:52 vostro openvpn[12392]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Sep 21 20:08:52 vostro openvpn[12392]: TCP/UDP: Socket bind failed on local address [AF_INET][undef]:1194: Address already in use
Sep 21 20:08:52 vostro openvpn[12392]: Exiting due to fatal error

I realized that I have openvpn clients bound to:

# netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
...
udp 0 0 0.0.0.0:50287 0.0.0.0:*
udp 0 0 0.0.0.0:openvpn 0.0.0.0:*
...
# lsof | grep 50287
openvpn 6823 openvpn 4u inet 47873 0t0 UDP *:50287
#

I added 'nobind' option to foo.conf (the settings for the third openvpn client connection) and now it happily connects:

Sep 21 20:14:22 vostro openvpn[12596]: Control Channel MTU parms [ L:9122 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Sep 21 20:14:22 vostro openvpn[12596]: GETADDRINFO flags=0x0901 ai_family=0 ai_socktype=2
Sep 21 20:14:22 vostro openvpn[12596]: RESOLVE_REMOTE flags=0x0901 phase=1 rrs=0 sig=-1 status=0
Sep 21 20:14:22 vostro openvpn[12596]: Data Channel MTU parms [ L:9122 D:9122 EF:122 EB:1656 ET:0 EL:3 AF:3/1 ]
Sep 21 20:14:22 vostro openvpn[12596]: crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by 40 bytes
Sep 21 20:14:22 vostro openvpn[12596]: calc_options_string_link_mtu: link-mtu 9122 -> 9042
Sep 21 20:14:22 vostro openvpn[12596]: crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by 40 bytes
Sep 21 20:14:22 vostro openvpn[12596]: calc_options_string_link_mtu: link-mtu 9122 -> 9042
Sep 21 20:14:22 vostro openvpn[12596]: Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 9042,tun-mtu 9000,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Sep 21 20:14:22 vostro openvpn[12596]: Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 9042,tun-mtu 9000,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Sep 21 20:14:22 vostro openvpn[12596]: TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:1194
Sep 21 20:14:22 vostro openvpn[12596]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Sep 21 20:14:22 vostro openvpn[12596]: UDP link local: (not bound)
Sep 21 20:14:22 vostro openvpn[12596]: UDP link remote: [AF_INET]xx.xx.xx.xx:1194

1. Please, improve the error message if openvpn cannot bind an iterface and include a note that there is a nobind option. The manpage is unclear it could be helpful in cases like this.

2. Could openvpn try to use 'nobind' approach if interface binding fails?

3. Why does that not happen for my second openvpn client connection already? Why only with the third one?

[David Sommerseth]

In at least TLS client mode, we can consider to use --nobind as the default. I don't guarantee we will do that, as this needs to be thoroughly checked to ensure the other operational modes (peer-to-peer/site-to-site) configurations will not fail or change the expectation too much. Especially site-to-site tunnels may have an advantage of having the bind happening to the same local port as the remote port. So this should cover question 2).

For question 1), that is not as easy as it sounds ... based what I already wrote in the paragraph above. But we could look at improving our documentation and see if we can do something about the "(not bound)" message.

In regards to question 3), it is hard to say without seeing any configuration files or logs. But my gut feeling tells me that the two first ones use different ports while the third tunnel uses the same port number as one of the prior ones.

When --nobind is not provided, it will bind the local port number to the same port number as the remote port number. That is the crucial detail.

[Gert Döring]

basically, what dazo says. Your "netstat" output shows that the two previous instances use different ports, and when you stop the one bound to 1194 ("openvpn"), this port can be reused by the third instance.

@dazo: we should default to --nobind if --client is set, I'd say. In 2.5, and properly document this.

This is one of the few options where we actually have -bind and --nobind, so we're not losing functionality (or have to introduce a new option) by changing the default. Honestly, I think --bind should have never been the default for client connections, but that's what we inherited...

[thofmann]

I also came accross this issue, via #877.

Please point me to a reading or elaborate on the background of the design choice of per default using the same port on the client side as is used to connect to the server. I could imagine that it is around the NAT-traversal problem when using UDP.

Upon further input on the actual background I second #877 in regards of deeming it at least a glitch, since client side ports should use a port out of the ephemeral port range (​https://en.wikipedia.org/wiki/Ephemeral_port) and been dynamically retrieved from the OS. That would not make assumptions on the availability of a specific port on the client-side by the configuration which usually is predifined by some means on the server-side. Also conflicts arising if using the default port and starting both a server and a client on the same host would be circumvented.

Sidenotes:

• The name "nobind" is misleading, a bind is still been made.
• lport/rport without further reading lead a misleading "left/right"-interpretation, instead of the intended "local/remote", I would rather prefer "client-port" and "server-port".

I understand changes to established APIs as beeing difficult, and sideeffects must clearly be considered, therefore I deem the fallback as described in "mmokrejs" first post ("2. Could openvpn try to use 'nobind' approach if interface binding fails?"), as a reasonable solution. Accompanied by a warning-output that the fallback had been used.

Maybe that could also lead to a development path via:

1. introducing fallback to "nobind"-behaviour
2. making "nobind" the default for pure client-connections
3. ... thinking about side-effects on other topologies ...
4. until the introduction of per default using an ephemeral port on the client-side.

Kind regards,
Thomas

[Gert Döring]

The answer basically is "when OpenVPN was first written, there was no concept of a 'client' or of a 'server', just peers, and ports needed to be known = bind".

Client-to-server came later, and that was never revisited.

Too late for 2.5, though. (Stealing the ticket from dazo).

[Gert Döring]

Confirming that we do want ---nobind by default on clients (---pull), and it is a MUST HAVE item in 2.6

[Gert Döring]

commit de02c828f5aa3fbaca78918d4392b48b47547770 (HEAD -> master)
Author: Arne Schwabe <arne@…>
Date: Mon Dec 6 02:00:07 2021 +0100

Make --nobind default for --pull

So, on a pure client setup, using --pull or --client (which implies --pull) OpenVPN no longer binds to a fixed port.

If --lport, --local or --bind are used, it still binds - and these are the cases that really need the binding, the other was just an oversight. Server, of course, also binds :-)

Closing this ticket, the change will be in 2.6.0, to be released early 2022.