Wireguard hanging on to previous IPv6

mcfly9

Hi, I have two sites, pfsense on both ends. Connectivity works great between the two sites, all good; generally no issues with the setup.
As end is on an FTTH connection that uses PPPoE my ISP every ~168 hours resets the connection (drops the PPPoE link), and reconnection gives me a new IP.

When this happens, sometimes the site-to-site link is not recovering. I did a packet capture and managed to catch something odd. Wireguard seems to hang on to the old IP and responds using the old ip as the source address:

14:10:06.278539 IP6 aaaa:bbbb:cccc:dddd::8.51823 > eeee:ffff:112:5f2:be24:11ff:fe6f:74c8.51821: UDP, length 148
14:10:06.279069 IP6 eeee:ffff:112:d:be24:11ff:fe6f:74c8.31380 > aaaa:bbbb:cccc:dddd::8.51823: UDP, length 92

Note the difference in the fourth block: 5f2 (new ip) vs d (previous ip). My ISP (correctly) drops these packets and the other end (aaaa:bbbb:cccc:dddd::8) doesn't receive them.

Where could I diagnose why wireguard hangs on to the previous IP?

Edit: pfsense CE 2.8.1, wireguard 0.2.9_6

Bob.Dig

@mcfly9 That is normal behavior and there are no mitigations in pfSense for that.

If one site has a static IP-address, the other one should make the connection, problem solved.

mcfly9

@Bob.Dig Any advice if both ends are on a dynamic connection?

Just adding, I have a similar setup working very nicely between two other sites both using dynamic pppoe connections, dynamic dns registering the endpoint address and using dns names as (fixed) endpoints: whenever one end has its WAN reconnecting, my experience is that that end will initiate a connection to the other end, the other end in turn will updat its own notion of the "calling" side end and connection resumes nicely.

On this very site I seem to have issues with wireguard hanging on to the old ipv6 address and this making resume impossible.
Nevertheless, I was able to work it around by executing pfctl -k <oldip>. I can probably create a script that on WAN reconnect it kills the states with the old IP. I am now also experimenting with setting the gateway to kill states on gateway down.

Anyway, this workaround immediately resolved the issue and made the connection work again.

mcfly9

Reporting back on my issue.

I am running a script that kills states for the IPv6 GUA when the PPPoE reconnect occurs. This consistently fixes my issue.

While understanding and accepting that using a dns name based "static" setup on a dynamic IP is not the intended usecase for wireguard, I am still wondering about the underlying behavior: why is there a stale state for my IPv6 GUA remaining after a PPPoE reconnect.

Some states seem to be killed during the reconnect:

Mar 29 10:51:53 pfSense php-cgi[82387]: rc.kill_states: rc.kill_states: Removing states for IP fe80::be24:11ff:fe6f:74c8%pppoe1/32
Mar 29 10:51:53 pfSense php-cgi[82387]: rc.kill_states: rc.kill_states: Removing states for interface pppoe1

But old GUA-related states seem to staying on somehow:

Mar 29 10:53:00 pfSense killstatescript[50247]: 2026-03-29 10:53:00 [wg-ipv6-watch] IPv6 changed on pppoe1: 2a01:....:....:6275:aaaa:bbbb:cccc:dddd -> 2a01:....:....:6a2:aaaa:bbbb:cccc:dddd
Mar 29 10:53:00 pfSense killstatescript[53030]: 2026-03-29 10:53:00 [wg-ipv6-watch] Executed: pfctl -k 2a01:....:....:6275:aaaa:bbbb:cccc:dddd
Mar 29 10:53:00 pfSense killstatescript[52180]: 2026-03-29 10:53:00 [wg-ipv6-watch] pfctl output: killed 7 states from 1 sources and 0 destinations

Summing it up: using a scheduled script that kills the GUA related states upon PPPoE reconnection made my setup reliably stable with both wireguard endpoints on a dynamic connections using dns names as endpoint definitions combined with DDNS registration.