Dear Maintainer, In version 2.3.4-5+deb8u2, if one had a setting of, e.g.: management tunnel 5656 the behaviour was as documented -- it would wait for the tunnel to come up, and then listen on port 5656 for the management interface. Having upgraded to 2.4.0-6+deb9u2, the port number seems to be ignored, as you can see here: # grep management /etc/openvpn/vpn1.conf management tunnel 5656 # netstat -tlnp | grep openvpn tcp 0 0 172.12.34.14:43125 0.0.0.0:* LISTEN 495/openvpn Downgrading to 2.3.4-5+deb8u2 restores the previous behaviour. It seems that if you specify an IP address, rather than "tunnel" then it uses a different code path, which does the listen before the tunnel comes up, and it does then use the specified port. This cannot be used as a workaround though if you want it to listen on the tunnel address, since the interface is not up at this point. Cheers, Phil.
#971: "management tunnel <port>" ignores port -------------------------------------+------------------------------------- Reporter: berni | Type: Bug / Defect Status: new | Priority: major Milestone: | Component: Management Version: OpenVPN 2.4.4 | Severity: Not set (select this (Community Ed) | one, unless your'e a OpenVPN Keywords: | developer) -------------------------------------+------------------------------------- This has been originally reported by a Debian user at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881901 Having upgraded to 2.4.0-6+deb9u2, the port number seems to be ignored, as you can see here: # grep management /etc/openvpn/vpn1.conf management tunnel 5656 # netstat -tlnp | grep openvpn tcp 0 0 172.12.34.14:43125 0.0.0.0:* LISTEN 495/openvpn Downgrading to 2.3.4-5+deb8u2 restores the previous behaviour. I've confirmed this to still be the case in 2.4.4
#971: "management tunnel <port>" ignores port
-------------------------------------+-------------------------------------
Reporter: berni | Owner: (none)
Type: Bug / Defect | Status: new
Priority: minor | Milestone:
Component: Management | Version: OpenVPN 2.4.4
Severity: Not set (select this | (Community Ed)
one, unless your'e a OpenVPN | Resolution:
developer) |
Keywords: |
-------------------------------------+-------------------------------------
Changes (by plaisthos):
* priority: major => minor
#971: "management tunnel <port>" ignores port
-------------------------------------+-------------------------------------
Reporter: berni | Owner: (none)
Type: Bug / Defect | Status: new
Priority: major | Milestone:
Component: Management | Version: OpenVPN 2.4.4
Severity: Not set (select this | (Community Ed)
one, unless your'e a OpenVPN | Resolution:
developer) |
Keywords: |
-------------------------------------+-------------------------------------
Comment (by plaisthos):
I think it might haven broken this back when I did the dual stack patches
that went into 2.4.0. Consider that this has now been broken the whole
time in 2.4.0 and we have only one report that noticed that this feature
is completely broken, I wonder if it might be better to just remove the
feature in 2.5.x rather to then try to fix a feature that seems not to be
used very much. To be honest I m not sure what the real use case for this
feature is anyway.
#971: "management tunnel <port>" ignores port
-------------------------------------+-------------------------------------
Reporter: berni | Owner: (none)
Type: Bug / Defect | Status: new
Priority: minor | Milestone:
Component: Management | Version: OpenVPN 2.4.4
Severity: Not set (select this | (Community Ed)
one, unless your'e a OpenVPN | Resolution:
developer) |
Keywords: |
-------------------------------------+-------------------------------------
Comment (by plaisthos):
Untested patch that should fix this:
https://gist.github.com/schwabe/5ee8361b3a0e4bc492f81e96149d8200
#971: "management tunnel <port>" ignores port
-------------------------------------+-------------------------------------
Reporter: berni | Owner: (none)
Type: Bug / Defect | Status: new
Priority: minor | Milestone:
Component: Management | Version: OpenVPN 2.4.4
Severity: Not set (select this | (Community Ed)
one, unless your'e a OpenVPN | Resolution:
developer) |
Keywords: |
-------------------------------------+-------------------------------------
Comment (by Gert Döring):
@berni: if we ignore your tickets, you know where to find and kick me :-)
- no bad intentions, just sometimes "no time to look through open trac
tickets", and then things slip... sorry.
#971: "management tunnel <port>" ignores port
-------------------------------------+-------------------------------------
Reporter: berni | Owner: (none)
Type: Bug / Defect | Status: new
Priority: minor | Milestone:
Component: Management | Version: OpenVPN 2.4.4
Severity: Not set (select this | (Community Ed)
one, unless your'e a OpenVPN | Resolution:
developer) |
Keywords: |
-------------------------------------+-------------------------------------
Comment (by tincantech):
Replying to [comment:4 plaisthos]:
> Untested patch that should fix this:
The patch does not fix the problem.
Note: build openvpn-git.master + the patch applied and `enable-systemd=no`
then use root terminal to start and restart the process.
For a while this patch appeared to work properly if `--server` was used
but after several tests even this config failed eventually.
On my first test, after 5 restarts the management port was correct and
listening on the tunnel interface.
On my second test, after 1 restart the port was randomised again ..
(Log file attached)
The following tests were run on my server which does not use `--server`
but instead manually expands the `--server` helper directive. (This is a
live server with one client and is in use everyday, it functions normally
in every other respect)
With `management tunnel 63110` in the config this happened:
* Init:
`Thu Feb 7 14:39:03 2019 us=862353 MANAGEMENT: TCP Socket listening on
[AF_INET]10.63.110.101:63110`
* SIGHUP 1 (`$ kill -1 $PID`)
`Thu Feb 7 14:39:43 2019 us=733816 MANAGEMENT: TCP Socket listening on
[AF_INET]10.63.110.101:63110`
* SIGHUP 2 (`$ kill -1 $PID`)
`Thu Feb 7 14:39:58 2019 us=845341 MANAGEMENT: TCP Socket listening on
[AF_INET]10.63.110.101:63110`
* SIGHUP 3 (`$ kill -1 $PID`)
`Thu Feb 7 14:40:12 2019 us=952338 MANAGEMENT: TCP Socket listening on
[AF_INET]10.63.110.101:63110`
* SIGHUP 4 (`$ kill -1 $PID`)
`Thu Feb 7 14:40:29 2019 us=61927 MANAGEMENT: TCP Socket listening on
[AF_INET]10.63.110.101:0`
* Netstat: `tcp 0 0 10.63.110.101:33655 0.0.0.0:*
LISTEN`
Running the same test a second time this happened:
* Init:
`Thu Feb 7 15:00:40 2019 us=5936 MANAGEMENT: TCP Socket listening on
[AF_INET]10.63.110.101:63110`
* SIGHUP 1 (`$ kill -1 $PID`)
`Thu Feb 7 15:01:19 2019 us=948595 MANAGEMENT: TCP Socket listening on
[AF_INET]10.63.110.101:0`
* Netstat: `tcp 0 0 10.63.110.101:35625 0.0.0.0:*
LISTEN`
#971: "management tunnel <port>" ignores port
-------------------------------------+-------------------------------------
Reporter: berni | Owner: (none)
Type: Bug / Defect | Status: new
Priority: minor | Milestone:
Component: Management | Version: OpenVPN 2.4.4
Severity: Not set (select this | (Community Ed)
one, unless your'e a OpenVPN | Resolution:
developer) |
Keywords: |
-------------------------------------+-------------------------------------
Changes (by tincantech):
* Attachment "server.log" added.
#971: "management tunnel <port>" ignores port
-------------------------------------+-------------------------------------
Reporter: berni | Owner: (none)
Type: Bug / Defect | Status: new
Priority: minor | Milestone:
Component: Management | Version: OpenVPN 2.4.4
Severity: Not set (select this | (Community Ed)
one, unless your'e a OpenVPN | Resolution:
developer) |
Keywords: |
-------------------------------------+-------------------------------------
Comment (by Philip Hands):
Replying to [comment:2 plaisthos]:
> I think it might haven broken this back when I did the dual stack
patches that went into 2.4.0. Consider that this has now been broken the
whole time in 2.4.0 and we have only one report that noticed that this
feature is completely broken, I wonder if it might be better to just
remove the feature in 2.5.x rather to then try to fix a feature that seems
not to be used very much. To be honest I m not sure what the real use case
for this feature is anyway.
It's always possible (although perhaps unlikely) that others experiencing
this bug could have seen the open report, and decided that they had
nothing to add.
Anyway, in case it makes any difference, my use case for this is that I'm
running OpenVPN on two servers, to provide redundancy, with the clients
configured almost at random to prefer one or the other.
In order to be able to route from any client to any other client,
regardless of which server they are connecting to, I run a script (cube-
routed) that looks at the state of logged in clients on the other server,
and adds routes (going via another OpenVPN link, between the servers) to
ensure that one can get to the clients that are attached to the other
server.
It works well enough, but if there's now a better way of achieving the
same aim, I'm fine with switching to another approach.
I am also happy to test either that alternative, or attempts to fix this
bug, so feel free to ask either way.
#971: "management tunnel <port>" ignores port
-------------------------------------+-------------------------------------
Reporter: berni | Owner: (none)
Type: Bug / Defect | Status: new
Priority: minor | Milestone:
Component: Management | Version: OpenVPN 2.4.4
Severity: Not set (select this | (Community Ed)
one, unless your'e a OpenVPN | Resolution:
developer) |
Keywords: |
-------------------------------------+-------------------------------------
Comment (by thhart):
I can confirm the patch fixes the problem for my installation.
I know this is a very rare used feature, however we use it for monitoring
connected clients heavily. I know there might be other possibilities to
achieve this but I think it is extremely hard to drop this feature while
it is "only" necessary to have this simple patch in place.
#971: "management tunnel <port>" ignores port
-------------------------------------+-------------------------------------
Reporter: berni | Owner: (none)
Type: Bug / Defect | Status: new
Priority: minor | Milestone:
Component: Management | Version: OpenVPN 2.4.4
Severity: Not set (select this | (Community Ed)
one, unless your'e a OpenVPN | Resolution:
developer) |
Keywords: |
-------------------------------------+-------------------------------------
Comment (by vetco):
I'd just like to contribute that we would also like to use this feature,
we have a VPN client that wants to know what connection is being used, the
easiest way would be to connect to the management on the server and list
the connection IP. This can't be done from the client daemon because it
thinks it's IP is 192.168.*.*