Specifically with iked, it makes debugging configurations remotely very tedious and time consuming since after stopping iked you have to wait a minute to ssh the server every time.
> On Dec 26, 2024, at 11:19 AM, Stuart Henderson <s...@spacehopper.org> wrote: > > On 2024/12/26 10:15, William Rusnack wrote: >>> Synopsis: iked leaves behind pf state entries for NAT-T (UDP 4500) upon >>> stopping >>> Category: bin >>> Description: >> When stopping iked with `rcctl stop iked`, the service leaves behind pf >> state entries for NAT-T (UDP 4500) that prevent normal network connectivity >> until they expire naturally (observed timeout ~1 minute). >> >> Example state entry that persists: >> all udp <client-lan-ip>:4500 <- <server-wan-ip>:4500 MULTIPLE:MULTIPLE >> age 00:03:15, expires in 00:00:59, 637:7 pkts, 111222:365 bytes, rule 1 >> id: 6755c8e800001230 creatorid: 7078d876 >> >> IMPACT: >> After stopping iked, connectivity to VPN endpoints remains broken until >> these state entries expire naturally. This prevents immediate restoration of >> normal network routing (ssh, ping, etc.) even after the VPN service is >> stopped. >> >>> How-To-Repeat: >> 1. Start iked with a configured VPN connection `iked -v -d` >> 2. Stop iked `ctl-c` >> 3. Observe persistent pf state entry for UDP 4500 `pfctl -vvv -s states | >> fgrep -A 2 4500` >> 4. Connectivity to VPN endpoint remains broken until state expires or killed >> with `pfctl -k id -k <state-id>` >> > > I don't think iked is expected to do that. > > libc doesn't clean PF states after doing DNS requests, either. >
