Following up on this one from the same team (I'm working on our pf migration with Andreas). We tried both suggestions and each one falls short in a way that would be helpful to get your take on. Provider that stays started and drops traffic while the tunnel is down. This blocks correctly, but it breaks captive portals. Starting with the full included routes before the tunnel is up sends ordinary sockets into the utun, including the browser and our own captive-portal detection probes. Detection never sees the portal, and the user can't reach the login page. Binding the probes to the physical interface doesn't help either: with enforceRoutes off, a socket bound to en0 (IP_BOUND_IF or a source-address bind) still can't reach a destination covered by the tunnel's included routes while the tunnel is connecting. It fails immediately, and only excluded ranges answer. Content filter cooperating with the provider. This mostly works while the tunnel is down. The gap is TCP: a blocked connect still puts its SYN on the wire before the verdict lands (the RST follows, with no payload). It also can't cover TunnelVision-style routes while the tunnel is connected. We'd like to run with enforceRoutes on but because of the socket kills in https://developer.apple.com/forums/thread/850873 we suspect customers will complain because of the disruptions. A more-specific route via the LAN gateway then sends tunnelled destinations out en0, and the filter never sees an unconnected UDP socket's local address, so it either lets those datagrams out en0 or blocks unconnected UDP into the tunnel too. We need split tunnelling, so includeAllNetworks is out. Two questions: Is there a supported way to close those gaps short of NEFilterPacketProvider, or is a packet filter the intended answer for blocking at the packet level? Routing your VPN network traffic says captive-portal negotiation traffic is always excluded from the tunnel under includeAllNetworks. Does that exemption also apply when enforceRoutes is set? And does it cover only the system's probe and Captive Network Assistant sheet, or browser traffic to the portal as well? If the answer is an enhancement request, I'm happy to file one.

Yes, that matches what we see. A socket that stays idle through the update and only sends afterwards has always survived for us, and every kill we timestamped happened while the update was in progress. One nuance -- sending during the update doesn't guarantee a kill. Only some of the sockets that were sending at the time died. This varied between test runs but averaged around 25% of sockets being killed but up to 60%. Apologies for the delayed response -- my notifications were setup incorrectly so didn't see your response til I manually checked.