Opened 3 years ago

Last modified 12 months ago

#971 new Bug / Defect

"management tunnel <port>" ignores port

Reported by: berni Owned by:
Priority: minor Milestone:
Component: Management Version: OpenVPN 2.4.4 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: 881901@…

Description

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

Attachments (1)

server.log (53.1 KB) - added by tincantech 20 months ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 3 years ago by tincantech

I can confirm this is also the case with
OpenVPN 2.5_git [git:master/c68a025a1ca687c1] x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Dec 31 2017

Also, while investigating I found that SIGHUP[hard,] received, process restarting (ie. # kill -1 $PID) the --management IP Port is not reloaded correctly.

Thus, starting config file with --management tunnel $port, the management port is opened on the tunnel interface with a random port, then changing the config file to --management 127.0.0.1 $port (saving config file) and restarting with kill -1 $PID, the process is restarted and the log shows that the change has been read eg: Sun Dec 31 14:54:46 2017 us=310025 management_addr = '127.0.0.1' but the port is re-opened on the tunnel interface with a random port. eg: Sun Dec 31 14:54:51 2017 us=541165 MANAGEMENT: TCP Socket listening on [AF_INET]10.63.110.101:0

comment:2 Changed 20 months ago 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.

comment:3 Changed 20 months ago by plaisthos

Priority: majorminor

comment:4 Changed 20 months ago by plaisthos

comment:5 Changed 20 months ago 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.

Changed 20 months ago by tincantech

Attachment: server.log added

comment:6 in reply to:  4 Changed 20 months ago by tincantech

Replying to 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 above)

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
Version 1, edited 20 months ago by tincantech (previous) (next) (diff)

comment:7 in reply to:  2 Changed 19 months ago by Philip Hands

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

comment:8 Changed 12 months ago 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.

Note: See TracTickets for help on using tickets.