management interface missing source port for ipv6 addresses

[furlongm]

When running any of the 'status' commands from the management interface, the "Real Address" column has a source port for ipv4 addresses, but not for ipv6 addresses.

For consistency, is it possible to add the source port for ipv6 addresses? (possibly using the typical [ipv6address]:port schema?)

[Gert Döring]

Please re-try with the current version (2.3.10). There have been changes to management interface output and internal address printing functions, and I'm not going back to 2.3.4 to search for something that might have long been fixed.

Which "status" version are you using? There's "status", "status 2", "status 3","status 4" and 3+4 display additional columns in a more extensible CSV format, so possibly the info is only there (due to constraints of status 1/2)

[furlongm]

I retried with 2.3.10. The same issue occurs, and it occurs with "status", "status 2" and "status 3". "status 4" does not work.

Compare the ipv6 version:

status 3
TITLE OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan 4 2016
TIME Wed Mar 2 21:26:37 2016 1456914397
HEADER CLIENT_LIST Common Name Real Address Virtual Address Bytes Received Bytes Sent Connected Since Connected Since (time_t) Username
CLIENT_LIST furlongm ::ffff:59.167.120.212 10.29.12.6 65056 92600 Wed Mar 2 21:25:18 2016 1456914318 furlongm
HEADER ROUTING_TABLE Virtual Address Common Name Real Address Last Ref Last Ref (time_t)
ROUTING_TABLE 10.29.12.6 furlongm ::ffff:59.167.120.212 Wed Mar 2 21:26:32 2016 1456914392
GLOBAL_STATS Max bcast/mcast queue length 0

with the ipv4 version:

status 3
TITLE OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan 4 2016
TIME Wed Mar 2 21:30:53 2016 1456914653
HEADER CLIENT_LIST Common Name Real Address Virtual Address Bytes Received Bytes Sent Connected Since Connected Since (time_t) Username
CLIENT_LIST furlongm 59.167.120.212:59560 10.29.12.6 1728 4061 Wed Mar 2 21:30:39 2016 1456914639 furlongm
HEADER ROUTING_TABLE Virtual Address Common Name Real Address Last Ref Last Ref (time_t)
ROUTING_TABLE 10.29.12.6 furlongm 59.167.120.212:59560 Wed Mar 2 21:30:44 2016 1456914644
GLOBAL_STATS Max bcast/mcast queue length 0
EN

i.e. 59.167.120.212:59560 vs ::ffff:59.167.120.212

Note the port missing at the end of the ipv6 address. I've also confirmed it happens with all ipv6 addresses, not just ipv4mapped addresses. The ipv6 address could (should?) be written [::ffff:59.167.120.212]:59560 with the port?

[furlongm]

According to rfc5952, there are a number of options for including the port in the text representation of an ipv6 address:

​http://tools.ietf.org/html/rfc5952#section-6

6. Notes on Combining IPv6 Addresses with Port Numbers

There are many different ways to combine IPv6 addresses and port
numbers that are represented in text. Examples are shown below.

o [2001:db8::1]:80
o 2001:db8::1:80
o 2001:db8::1.80
o 2001:db8::1 port 80
o 2001:db8::1p80
o 2001:db8::1#80

[furlongm]

Using the format 2001:db8::1#80 seems the least intrusive idea:

Using [2001:db8::1]:80 would results in undesirable square brackets if a prefix is included (e.g. [2001:db8::1]/64)

Using 2001:db8::1:80 is ambiguous.

Using 2001:db8::1.80 should be avoided due to ambiguity with dots being used in ipv4 addresses.

Using 2001:db8::1 port 80 might not be preferable due to the inclusion of spaces.

Using 2001:db8::1p80 is also an option but 2001:db8::1#80 seems clearer.

I've attached a patch using 2001:db8::1#80 and confirmed that it works as expected.

[furlongm]

This bug causes an issue in a client that parses the output of the management interface. The above patch corrects the issue and makes the output consistent for both ipv4 and ipv6 addresses.

See ​https://github.com/furlongm/openvpn-monitor/issues/6#issuecomment-190745431 for further information.

[Gert Döring]

please test whether the client is fine with the output format of OpenVPN git master - which became consistent somewhat by accident, by not displaying port numbers for either v4 or v6. We could backport that change to 2.3

[furlongm]

Is that not a regression?

The port numbers help to uniquely identify each connection. The "source address:source port" combination is the only dependable unique identifier. For ipv4mapped addresses (ipv4 addresses displayed in ipv6) you can have multiple connections from the same source address, so the ipv6 address is no longer a unique identifier. There are also other cases (e.g. ip address exhaustion on the openvpn server, or before a local ip address has been assigned) where there is a connection, but there is no local/global ip address combination to use as a unique identifier. In these cases, the "source address:source port" combination is the only way to uniquely identify connections.

The client depends on the port numbers being there so it will not work.

Is there a reason to not display the source port?

[furlongm]

Another issue is the kill command in the management interface.

It expects either a common name or an IP:Port combination.

Without an IP:Port combination it is only possible to kill a connection by common name, which will kill *all* connections using that common name. As the port is no longer displayed, we cannot discover the IP:Port combinations, and so can only kill by common name.

[Gert Döring]

you really should use the client ID to kill clients.

[furlongm]

How can I get the client ID from the status command?

[Gert Döring]

you need to use "status" or "status 2" or "3", not "status 1". Then you'll see the client ID as second-to-last column

HEADER,CLIENT_LIST,Common Name,Real Address,Virtual Address,Virtual IPv6 Address,Bytes Received,Bytes Sent,Connected Since,Connected Since (time_t),Username,Client ID,Peer ID

(peer-ID is for floating, and might be -1 if the client does not support it, client ID is an internal number that uniquely identifies a particular client)

[furlongm]

I don't seem to have that column. Does it exist in 2.3?

status
OpenVPN CLIENT LIST
Updated,Thu Dec 15 08:19:00 2016
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
furlongm,::ffff:59.167.12.216,20928957,83730173,Wed Dec 14 22:38:00 2016
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.29.10.6,furlongm,::ffff:59.167.12.216,Thu Dec 15 08:19:00 2016
GLOBAL STATS
Max bcast/mcast queue length,0
END

status 2
TITLE,OpenVPN 2.3.12 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Aug 23 2016
TIME,Thu Dec 15 08:19:09 2016,1481750349
HEADER,CLIENT_LIST,Common Name,Real Address,Virtual Address,Bytes Received,Bytes Sent,Connected Since,Connected Since (time_t),Username
CLIENT_LIST,furlongm,::ffff:59.167.12.216,10.29.10.6,20951136,83747111,Wed Dec 14 22:38:00 2016,1481715480,furlongm
HEADER,ROUTING_TABLE,Virtual Address,Common Name,Real Address,Last Ref,Last Ref (time_t)
ROUTING_TABLE,10.29.10.6,furlongm,::ffff:59.167.12.216,Thu Dec 15 08:19:09 2016,1481750349
GLOBAL_STATS,Max bcast/mcast queue length,0
END

status 3
TITLE   OpenVPN 2.3.12 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Aug 23 2016
TIME    Thu Dec 15 08:19:12 2016        1481750352
HEADER  CLIENT_LIST     Common Name     Real Address    Virtual Address Bytes Received  Bytes Sent      Connected Since Connected Since (time_t)        Username
CLIENT_LIST     furlongm        ::ffff:59.167.12.216   10.29.10.6      20951665        83748346        Wed Dec 14 22:38:00 2016        1481715480      furlongm
HEADER  ROUTING_TABLE   Virtual Address Common Name     Real Address    Last Ref        Last Ref (time_t)
ROUTING_TABLE   10.29.10.6      furlongm        ::ffff:59.167.12.216   Thu Dec 15 08:19:11 2016        1481750351
GLOBAL_STATS    Max bcast/mcast queue length    0
END

[furlongm]

Or is it only in 2.4?

Or does it not exist due to the options I am running openvpn with?

[Gert Döring]

Coming back to this. Sorry. We've all been a bit overloaded with other stuff.

I've fixed port numbers for the v4-mapped case (using regular v4-style :port notation), and opened a discussion on the openvpn-devel on "which format do we want to use for v6".

Thanks for all the pointers, very useful.