macOS and UDP/IPv6 floating fails

[cron2]

Setup

• Laptop, with LAN and WiFi, both networks with v4 and v6
• macOSs Ventura 13.7.8
• openvpn connection using --proto udp6, no bind, no multihome
• connect, run ping through the VPN, unplug LAN
• expected behaviour: connection moves to the "wifi" source IP, server logs a "float" event
• this used to work (I used this to test FreeBSD kernel floating)

observed behaviour:

2026-07-28 14:13:02 GERT: link_socket_write_udp_posix(->sendto()), scope_id=0
2026-07-28 14:13:02 GERT: link_socket_write_udp_posix(->sendto()), scope_id=0
2026-07-28 14:13:03 GERT: link_socket_write_udp_posix(->sendto()), scope_id=0
2026-07-28 14:13:03 write UDPv6: Can't assign requested address (fd=3,code=49)
2026-07-28 14:13:03 GERT: link_socket_write_udp_posix(->sendto()), scope_id=0
2026-07-28 14:13:03 write UDPv6: Can't assign requested address (fd=3,code=49)
2026-07-28 14:13:03 GERT: link_socket_write_udp_posix(->sendto()), scope_id=0
2026-07-28 14:13:03 write UDPv6: Can't assign requested address (fd=3,code=49)
2026-07-28 14:13:04 GERT: link_socket_write_udp_posix(->sendto()), scope_id=0
2026-07-28 14:13:04 write UDPv6: Can't assign requested address (fd=3,code=49)

(the "GERT" lines are obviously debug added to make sure I'm staring at the right system call)

A minimum test program with sendto() does not exhibit the issue - it will just happily change the emitted source address to "the new interface" and back, both for v4 and v6. Test program attached.
upkt.c

--multihome does not work to work around this (because the client will stick to the last inbound target IP seen, and that will not work anywhere else).

[cron2]

This is affecting my users, and since "just use IPv4" will "fix" it, it highly annoys me.

The question is "what are we doing to the socket that might cause this?" and also "what can we do to fix it" (treat "code=49" as "fatal, reconnect" would be one option, but that's not what we wrote all the server side float code for)...?!

[cron2]

OK, so I found the triggering issue - overlapped routes "in VPN" and "to the VPN server"

2026-07-28 15:20:52 GDG6: remote_host_ipv6=2001:67c:158c:ffff::4
2026-07-28 15:20:52 ROUTE6: 2001:67c:158c::/48 overlaps IPv6 remote 2001:67c:158c:ffff::4, adding host route to VPN endpoint
...
2026-07-28 15:20:52 add_route_ipv6(2001:67c:158c:ffff::4/128 -> fe80::1%en7 metric 1) dev en7
2026-07-28 15:20:52 /sbin/route add -inet6 2001:67c:158c:ffff::4 -prefixlen 128 fe80::1%en7
add host 2001:67c:158c:ffff::4: gateway fe80::1%en7

(this /48 should not have been pushed in the first place, I do push all the more specifics besides the ffff /64, but seem to have forgotten to take the /48 itself out)

so when the LAN interface goes away, macOS seems to "cling" to that route, and that makes the sendto() call fail.

With such a route in place (manually), the "upkt.c" test program fails in exactly the same way.

This generally positive, because we understand the trigger.

Now... for those users that want overlaps (--redirect-gateway), how can we make OpenVPN "fail over faster"? Right now it tries in vain until --keepalive 10 120 times out, which is more annoying than necessary. Can we treat -49 as "this is game over, disconnect, reconnect right away" in a nice way in the code?

[cron2]

https://gerrit.openvpn.net/c/openvpn/+/1830

this will make the openvpn client on macOS notice and restart the instance - reducing "my VPN is not working" downtime from keepalive timeout (120 seconds here) to ~2-3 seconds.

Future work definitely should have "monitor the routing socket, understand how the underlying topology looks like, and just reinstall the needed host routes" but that is slightly non-trivial. Linux could go VRF/ip policy instead, but macOS does not give us a way to do that.