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

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 :-)

Start with Gerrit change 1248 and issue #850, then trace the SIGUSR1 reconnect path where saved ifconfig values are restored. The fix is complete when the client restores its configured IPv4 netmask and IPv6 netbits and remote address after alternating pushed address families; verify the reconnect behavior against the examples in this issue.