remaining edge-case with reconnections, saved ifconfig, and netmask...

[cron2]

https://gerrit.openvpn.net/c/openvpn/+/1248 and #850 address the issue

• a client connects, receives a v4 or v6 address (ifconfig or ifconfig-ipv6 from server) and has --persist-tun
• the client does a SIGUSR1 reconnect, and on reconnect, the server sends a different set of ifconfigs - like, v4 on first connect, v6 on second connect, or vice versa
• gerrit 1248 ensures that the "other" address family's ifconfig is reset to the pre-connect saved value

this works well for the "client has no local ifconfig" case, but uncovered a new corner case (that also did never work):

client with --ifconfig 10.0.0.22 255.255.255.0 --pull

server pushing v6 only

2025-10-09 19:13:20 PUSH: Received control message: 'PUSH_REPLY,route 10.204.0.0 255.255.0.0,route-ipv6 fd00:abcd:204::/48,tun-ipv6,route-gateway 194.97.145.73,topology subnet,ping 10,ping-restart 30,compress stub-v2,ifconfig-ipv6 2001:608:3:814::1004/64 2001:608:3:814::1,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500'
2025-10-09 19:13:20 /sbin/ifconfig tun20 10.0.0.22/24 mtu 1500 up
2025-10-09 19:13:20 /sbin/ifconfig tun20 inet6 2001:608:3:814::1004/64 mtu 1500 up

(this is expected and fine, as ifconfig from the local config takes effect, plus pushed-ifconfig-ipv6)

client reconnects, server pushing v4 only this time

2025-10-09 19:14:09 PUSH: Received control message: 'PUSH_REPLY,route 10.204.0.0 255.255.0.0,route-ipv6 fd00:abcd:204::/48,tun-ipv6,route-gateway 194.97.145.73,topology subnet,ping 10,ping-restart 30,compress stub-v2,ifconfig 194.97.145.78 255.255.255.248,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500'
2025-10-09 19:14:10 /sbin/ifconfig tun20 194.97.145.78/29 mtu 1500 up

2025-10-09 19:14:10 WARNING: OpenVPN was configured to add an IPv6 route. However, no IPv6 has been configured for tun20, therefore the route installation may fail or may not work as expected.
2025-10-09 19:14:10 add_route_ipv6(fd00:abcd:204::/48 -> 2001:608:3:814::1 metric 200) dev tun20

(this is ok)

client reconnects again, this time only receiving v6

2025-10-09 19:15:20 PUSH: Received control message: 'PUSH_REPLY,route 10.204.0.0 255.255.0.0,route-ipv6 fd00:abcd:204::/48,tun-ipv6,route-gateway 194.97.145.73,topology subnet,ping 10,ping-restart 30,compress stub-v2,ifconfig-ipv6 2001:608:3:814::1004/64 2001:608:3:814::1,peer-id 0,auth-tokenSESS_ID,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500'
2025-10-09 19:15:21 /sbin/ifconfig tun20 10.0.0.22/29 mtu 1500 up
2025-10-09 19:15:21 /sbin/ifconfig tun20 inet6 2001:608:3:814::1004/64 mtu 1500 up

... and this is not fully OK. ifconfig falls back to the client config setup, but with the wrong netmask (/29, as was previously pushed by the server, and not /24, as is configured).

This is not surprising as we only save ifconfig_local and ifconfig_ipv6_local, and not ifconfig_remote_netmask (v4), ifconfig_ipv6_netbits and ifconfig_ipv6_remote (v6). Trivial addition :-)

[cron2]

Also, --redirect-gateway and all its flags?

There is https://gerrit.openvpn.net/c/openvpn/+/1210/4/src/openvpn/init.c which adds a special clause "only execute redirect-gateway ipv6 if we have a valid ipv6 address", but that's actually different from what we used to do "if a user wants to shoot themselves, they are free to do that (we log a warning, and still execute the route-ipv6 statements).