Wrong source IP for UDP replies

[WGH-]

Happy New Year! 🎄

Suppose I have a WireGuard interface configured like this:

Endpoint = [${PREFIX}:${EUI64}]:51821

The endpoint host/port pair is a phantun client. The host IP is a stable IPv6 address derived from the MAC address, and doesn't change.

When WireGuard does the handshake, we get this sequence of packets:

03:41:17.324203 IP6 ${PREFIX}:${WGCLIENT}.40677 > ${PREFIX}:${EUI64}.51821 UDP, length 148
03:41:17.414077 IP6 ${PREFIX}:${TMP}.51821 > ${PREFIX}:${WGCLIENT}.40677: UDP, length 92
03:41:17.414823 IP6 ${PREFIX}:${WGCLIENT}.40677 > ${PREFIX}:${TMP}.51821: UDP, length 32

Note that the phantun client uses a different IP address for replies. Instead of ${PREFIX}:${EUI64} it uses ${PREFIX}:${TMP}.

It doesn't immediately break WireGuard, as it's tolerant to address changes, and simply updates the endpoint address to ${PREFIX}:${TMP} and goes on.

However, phantun keeps using this TMP addresses forever.

See, the TMP is a temporary IPv6 address generated by the privacy extensions. These addresses are periodically rotated. Here is except from ip address output:

2: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet6 ${PREFIX}:${TMP}/64 scope global temporary dynamic
       valid_lft 527568sec preferred_lft 8597sec
    inet6 ${PREFIX}:${TMP2}/64 scope global temporary deprecated dynamic
       valid_lft 441740sec preferred_lft 0sec
    inet6 ${PREFIX}:${TMP3}/64 scope global temporary deprecated dynamic
       valid_lft 355913sec preferred_lft 0sec
    inet6 ${PREFIX}:${TMP4}/64 scope global temporary deprecated dynamic
       valid_lft 270085sec preferred_lft 0sec
    inet6 ${PREFIX}:${TMP5}/64 scope global temporary deprecated dynamic
       valid_lft 184258sec preferred_lft 0sec
    inet6 ${PREFIX}:${TMP6}/64 scope global temporary deprecated dynamic
       valid_lft 98430sec preferred_lft 0sec
    inet6 ${PREFIX}:${TMP7}/64 scope global temporary deprecated dynamic
       valid_lft 12602sec preferred_lft 0sec
    inet6 ${PREFIX}:${EUI64}/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 2591800sec preferred_lft 604600sec

The address will become invalid after a week, and the connection will cease functioning.

I think we need to remember the destination IP on which UDP packet initially arrived, and use this IP as source. This is somewhat complicated, as it needs IP_PKTINFO sockopt to retrieve it, and then a bind call to set it. See, for example, quic-go fixing the same problem.

We could let the kernel choose the source IP for every packet instead by forgoing connect and replacing it with bind+sendto, but even then it may break in some scenarios. If WireGuard connection becomes idle for a week, the peer may remember the old temporary address and never get an updated one before the old one becomes invalid.

[dndx]

Can you create a NAT rule to help Phantun SNAT to the correct source address? Phantun does not have any ability to track dynamically changing IPv6 address yet nor does it understands IPv6 privacy extension.

[WGH-]

Can you create a NAT rule to help Phantun SNAT to the correct source address?

Not really? If remote peer does use our temporary address then phantun should reply from the same address. I don't think it's possible to express that in netfilter. I'm pretty sure replies that originate from the wrong source would be considered a new conntrack entry.

Phantun does not have any ability to track dynamically changing IPv6 address yet nor does it understands IPv6 privacy extension.

My proposed fix (#178) is not about tracking anything. It's about replying using the same source address as remote UDP peer used as destination to contact us.