Opened 8 years ago

Last modified 3 years ago

#877 accepted Feature Wish

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

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

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 (12)

comment:1 Changed 8 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 8 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 8 years ago by NHellFire (previous) (diff)

comment:3 in reply to:  2 ; Changed 8 years ago by 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 ?

Last edited 8 years ago by tct (previous) (diff)

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

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

Replying to NHellFire:

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

Sorry, my mistake.

Version 0, edited 8 years ago by tct (next)

comment:8 Changed 8 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 8 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).

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

Milestone: release 2.6

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

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

Owner: set to Gert Döring
Status: newaccepted

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

Cc: plaisthos added

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...

Note: See TracTickets for help on using tickets.