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
Priority: | major → minor |
---|---|
Type: | Bug / Defect → Feature Wish |
comment:2 follow-up: 3 Changed 8 years ago by
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
.
comment:3 follow-up: 4 Changed 8 years ago by
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
?
comment:4 Changed 8 years ago by
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 follow-up: 6 Changed 8 years ago by
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 follow-up: 7 Changed 8 years ago by
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 Changed 8 years ago by
Replying to NHellFire:
I can't use use
nobind
becausenobind
andlocal
are mutually exclusive.
Sorry, my mistake.
comment:8 follow-up: 9 Changed 8 years ago by
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 Changed 8 years ago by
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 addinglport 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
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
Owner: | set to Gert Döring |
---|---|
Status: | new → accepted |
comment:12 Changed 3 years ago by
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...
if you want
--lport 0
, then configure it as such.Since the existing default is documented as such
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 byport
- 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.