Status File v2 uses inconsistent values for Real Address field in IPv4 vs IPv6 cases

[domdom82]

IMPORTANT NOTE
Bugs about OpenVPN Access Server, OpenVPN Connect or any other product by OpenVPN Inc. should be directly reported to OpenVPN Inc. at https://support.openvpn.net

Describe the bug
I wrote a parser for the OpenVPN status file. The parser works fine for IPv4 clients but fails for IPv6 clients.
The reason is a discrepancy in how OpenVPN records the Real Address field in the status file:

IPv4 Case

TITLE,OpenVPN 2.6.14 aarch64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
TIME,2026-01-24 14:47:42,1769266062
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,Data Channel Cipher
CLIENT_LIST,vpn-client-0,192.168.100.3:52956,,fd8f:6d53:b97a:1::100:3,4167,6158,2026-01-24 14:47:28,1769266048,UNDEF,1,1,AES-256-GCM
CLIENT_LIST,vpn-client-0,10.10.0.2:38492,,fd8f:6d53:b97a:1::100:4,4081,5862,2026-01-24 14:47:28,1769266048,UNDEF,2,2,AES-256-GCM
CLIENT_LIST,vpn-client-0,192.168.100.2:49434,,fd8f:6d53:b97a:1::100:2,4073,6502,2026-01-24 14:47:27,1769266047,UNDEF,0,0,AES-256-GCM
HEADER,ROUTING_TABLE,Virtual Address,Common Name,Real Address,Last Ref,Last Ref (time_t)
ROUTING_TABLE,1a:66:09:f3:13:95@0,vpn-client-0,192.168.100.2:49434,2026-01-24 14:47:27,1769266047
ROUTING_TABLE,ca:a2:93:37:0c:15@0,vpn-client-0,10.10.0.2:38492,2026-01-24 14:47:28,1769266048
ROUTING_TABLE,ea:95:25:0f:72:df@0,vpn-client-0,192.168.100.3:52956,2026-01-24 14:47:28,1769266048
GLOBAL_STATS,Max bcast/mcast queue length,6
GLOBAL_STATS,dco_enabled,0
END

The Real Address field is recorded as an endpoint, i.e. <IPv4 address>:<port>, e.g.

192.168.100.3:52956

IPv6 Case

TITLE,OpenVPN 2.6.14 aarch64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
TIME,2026-01-24 14:32:15,1769265135
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,Data Channel Cipher
CLIENT_LIST,vpn-client-0,fd43:7ff4:965a::4,,fd8f:6d53:b97a:1::100:2,4635,10364,2026-01-24 14:30:29,1769265029,UNDEF,0,0,AES-256-GCM
CLIENT_LIST,vpn-client-0,fd00:10:1::2,,fd8f:6d53:b97a:1::100:4,7493,6898,2026-01-24 14:30:29,1769265029,UNDEF,2,2,AES-256-GCM
CLIENT_LIST,vpn-client-0,fd43:7ff4:965a::5,,fd8f:6d53:b97a:1::100:3,4635,9980,2026-01-24 14:30:29,1769265029,UNDEF,1,1,AES-256-GCM
HEADER,ROUTING_TABLE,Virtual Address,Common Name,Real Address,Last Ref,Last Ref (time_t)
ROUTING_TABLE,4e:90:64:dc:24:71@0,vpn-client-0,fd00:10:1::2,2026-01-24 14:30:29,1769265029
ROUTING_TABLE,86:4c:df:7f:36:8f@0,vpn-client-0,fd43:7ff4:965a::4,2026-01-24 14:30:29,1769265029
ROUTING_TABLE,ae:33:8c:b6:1b:f1@0,vpn-client-0,fd43:7ff4:965a::5,2026-01-24 14:30:29,1769265029
GLOBAL_STATS,Max bcast/mcast queue length,7
GLOBAL_STATS,dco_enabled,0
END

The Real Address field is recorded as an <IPv6 address> only, so the port is missing e.g.

fd43:7ff4:965a::4

This is very confusing for anyone trying to parse this file as the same field has different formats depending on the type of IP address of the client. To me this feels like a bug. The field format should be consistent, regardless of the IP version.

To Reproduce

1. Set up a vpn-server:

mode server
tls-server
topology subnet

ca /cacert.pem
cert /vpn-server/cert.pem
key /vpn-server/key.pem
cipher AES-128-GCM
dh /dh2048.pem

dev tap0
server-ipv6 fd8f:6d53:b97a:1::100:0/112

client-to-client
duplicate-cn

keepalive 10 60
proto tcp6-server

status /var/run/vpn-server.status 15
status-version 2

2. Set up an IPv4 client:

client
tls-client
pull

ca /cacert.pem
cert /vpn-client/cert.pem
key /vpn-client/key.pem

dev tap0
remote vpn-server

keepalive 10 60
proto tcp4-client

3. Set up an IPv6 client:

client
tls-client
pull

ca /cacert.pem
cert /vpn-client/cert.pem
key /vpn-client/key.pem

dev tap0
remote vpn-server

keepalive 10 60
proto tcp6-client

4. Start everything and let the clients connect
5. Observe the status file in /var/run/vpn-server.status

Expected behavior

Both vpn-clients should be recorded the same way in the status file, regardless of their IP version.
I would personally prefer to use the endpoint format, e.g. <IP>:<Port> in both cases.

Version information (please complete the following information):

• OS: Ubuntu 24.04.3 LTS
• OpenVPN version: 2.6.14

[cron2]

This has been a bit in flux - the problem with <ipv6:port> notation is that it's unclear if there is a port or not, as :1234 could be the source port or the last part of the IPv6 address.

So 2.7 will report status 2 with v4 and v6 clients as follows:

CLIENT_LIST,freebsd-14-amd64,udp6:[2001:608:0:814::fb00:14]:18949,10.220.2.4,fd00:abcd:220:2::1002,4928,4655,2026-01-24 16:39:31,1769269171,UNDEF,11,1,AES-256-GCM
CLIENT_LIST,freebsd-74-amd64,udp6:194.97.140.3:63504,10.220.2.8,fd00:abcd:220:2::1006,754425,761817,2026-01-24 06:57:45,1769234265,UNDEF,0,0,AES-256-GCM

(and you could see "tcp" and "udp" clients mixed in the same server, so adding the protocol was needed - udp6 signals that this was on an IPv6 UDP socket which can do dual-stack on most OSes).

For 2.6, we're not going to change the format within a release train.

[domdom82]

@cron2 Thank you for the quick reply. Good to know it will be fixed in 2.7

I will update my parser to handle both variants.