Clients bound to a specific IP don't use a random outgoing port

[NHellFire]

On one of my systems, I'm running an OpenVPN server as well as a client.
This system has 5 public IPs with the OpenVPN server bound to 0.0.0.0:1194, and the client bound to one of the public IPs (--local 1.1.1.1), connecting to server2.domain.com:1194 (using --remote server2.domain.com 1194)

As --port defaults to 1194, the client was bound to 1.1.1.1:1194 and not receiving data (was being received by the server instead). --lport should probably default to 0 (random) and --rport to 1194.

[Gert Döring]

if you want --lport 0 , then configure it as such.

Since the existing default is documented as such

       --port port
              TCP/UDP port number or port name for both local and remote (sets
              both  --lport  and  --rport options to given port).  The current
              default of 1194 represents the official IANA port number assign-
              ment  for  OpenVPN  and  has been used since version 2.0-beta17.
              Previous versions used port 5000 as the default.

this is not a bug, and certainly not "major"...

I could see it being a feature wish, to have lport default to 0, unless set by port - but then, I'm sure other users rely on the existing behaviour, so it would break existing setups. As such, it's unlikely that we'll change this.

[NHellFire]

Tickets default to bug & major. Local port defaults to random for *any* other network application, so yes, I'd call this a bug. It's highly unlikely anyone relies on the default lport being 1194 since client config samples -- including the ones shipped with openvpn -- include nobind, meaning they don't call bind() and use the OS default, which is random.

The exact same setup worked with OpenVPN 2.3, so something must have changed in 2.4. The only changes I've made to my config files since initial deployment are adding lport 0 .

[tct]

Replying to NHellFire :

the ones shipped with openvpn -- include nobind

For good reason.

The exact same setup worked with OpenVPN 2.3, so something must have changed in 2.4. The only changes I've made to my config files since initial deployment are adding lport 0 .

Why ?

However, I am curious to know if there is a genuine reason to set --lport 0 ?

[NHellFire]

Replying to tincantech :

Replying to NHellFire :

the ones shipped with openvpn -- include nobind

For good reason.

As I said, I'm binding to a specific IP.
My point was: It's extremely unlikely anyone depends on binding the client to 1194
Clients do not need to bind to a specific port (except in extremely rare cases like highly restrictive firewalls), and even then the port would likely be changed due to NAT.

The exact same setup worked with OpenVPN 2.3, so something must have changed in 2.4. The only changes I've made to my config files since initial deployment are adding lport 0 .

Why ?

However, I am curious to know if there is a genuine reason to set --lport 0 ?

Again: I'm binding to a specific IP. Without that it also binds the client to 1194. lport 0 is random, the OS default and for any other network application. That was added after updating to 2.4 because the same config I've been using 2.2 no longer worked.

[tct]

Replying to NHellFire :

--lport should probably default to 0 (random) and --rport to 1194.

--nobind does exactly that. You don't need --lport 0

[NHellFire]

Replying to tincantech :

Replying to NHellFire :

--lport should probably default to 0 (random) and --rport to 1194.

--nobind does exactly that. You don't need --lport 0

For the third time: I'm binding the client to a specific IP. Therefore I can't use use nobind because nobind and local are mutually exclusive.

[tct]

Replying to NHellFire :

I can't use use nobind because nobind and local are mutually exclusive.

Sorry, my mistake.

I just tested a client with --local x.x.x.x --lport 0 and it works.

With --local x.x.x.x --lport 0:

# netstat -anup
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp        0      0 10.10.201.238:48390     0.0.0.0:*                           14469/openvpn

With --nobind:

# netstat -anup
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp        0      0 0.0.0.0:53827           0.0.0.0:*                           14512/openvpn   

[NHellFire]

I never said lport 0 doesn't work. I said the same config I've been using since at least v2.2 no longer worked after updating to v2.4 and required adding lport 0 .

[Gert Döring]

Replying to NHellFire :

I never said lport 0 doesn't work. I said the same config I've been using since at least v2.2 no longer worked after updating to v2.4 and required adding lport 0 .

Which would indeed make this a bug. I'll go and run some tests and try to figure out which commit had this change as a side effect... (the whole socket listen/connect part was rewritten for 2.4 to enable proper dual-stacking).

[Gert Döring]

Revisit this before 2.6 release, when changing the ---bind default for --pull clients, we can also set the --lport default to 0. Possibly.

[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 :-)

Now, revisit the --lport 0 thing...