#1086·openvpn

macOS and UDP/IPv6 floating fails

Author: cron2Created Jul 28, 2026Updated Jul 29, 2026
LabelsenhancementmacOS

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