Opened 3 years ago

Last modified 3 years ago

#877 new Feature Wish

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

Reported by: NHellFire Owned by:
Priority: minor Milestone:
Component: Configuration Version: OpenVPN 2.4.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

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.

Change History (9)

comment:1 Changed 3 years ago by Gert Döring

Priority: majorminor
Type: Bug / DefectFeature Wish

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.

comment:2 Changed 3 years ago by 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.

Last edited 3 years ago by NHellFire (previous) (diff)

comment:3 in reply to:  2 ; Changed 3 years ago by tincantech

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 ?

Last edited 3 years ago by tincantech (previous) (diff)

comment:4 in reply to:  3 Changed 3 years ago by 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.

comment:5 in reply to:  description ; Changed 3 years ago by 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

comment:6 in reply to:  5 ; Changed 3 years ago by 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.

comment:7 in reply to:  6 Changed 3 years ago by tincantech

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   

Last edited 3 years ago by tincantech (previous) (diff)

comment:8 Changed 3 years ago by 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.

comment:9 in reply to:  8 Changed 3 years ago by 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).

Note: See TracTickets for help on using tickets.