At SURF, a mix of Linux, macOS, and Windows laptops use eduVPN every day. About two years ago the eduVPN GÉANT support team began receiving sporadic reports from macOS users: “eduVPN doesn’t work after laptop suspend.” The problem was intermittent and hard to pin down. During testing, it even disappeared for a while, only to resurface months later.
An early clue came from the macOS Application Firewall. We experimented with explicitly blocking the eduVPN Tunnel Extension — the component in our macOS/iOS app that runs the VPN daemon — using socketfilterfw, Apple’s built‑in app-level firewall:
/usr/libexec/ApplicationFirewall/socketfilterfw –blockapp /Applications/eduVPN.app/Contents/PlugIns/TunnelExtension-macOS.appex
Surprisingly, even with the extension blocked, the VPN sometimes still worked. Other times the firewall cut the traffic. That inconsistency told us the firewall was involved, but not in a straightforward way.
To make the issue reproducible and capture the right data, we built an automated test rig: a macOS laptop, a Raspberry Pi Pico emulating a USB keyboard, and a looped script. The script put the laptop to sleep; the Pico woke it by pressing the space key and entered the user’s password to perform a normal login. After wake, the script ran a series of ping tests. On success, it went back to sleep and repeated. On failure, it automatically grabbed Wireshark traces, dumped the routing table, and collected system logs.
We noticed the problem only occurred on managed macOS devices in SURF offices. Those machines are administered with Jamf and receive centrally managed configurations. That narrowed the scope to policy or software interactions, rather than a generic client bug. Reviewing the system log immediately after a failed wake pointed to socketfilterfw as the component enforcing the block.
Root cause
On macOS systems with “Block all incoming connections” enabled (a non default setting), the Application Firewall eventually creates a DENY rule for the eduVPN Network Extension (TunnelExtension-macOS.appex). Once present, that rule blocks the VPN’s traffic — in our traces even outgoing UDP — which explains the “eduVPN doesn’t work after suspend” reports. Why would macOS add such a rule? Our working theory is that, because VPN transport is typically UDP and therefore connectionless, after a brief sleep/wake the firewall no longer associates the outbound packets with a user-initiated flow and applies the block.
Picture of macOS Firewall settings when”Block all incoming connections” has been enabled. Viewable on macOS: Settings – Network – Firewall – “options”
How to fix it
If you want to keep “Block all incoming connections” enabled, add an explicit ALLOW rule for the eduVPN Tunnel Extension.
- Check whether a rule already exists:
/usr/libexec/ApplicationFirewall/socketfilterfw – -listapps | grep -i eduvpn - If there is an existing DENY rule for the Tunnel Extension, change it to ALLOW:
/usr/libexec/ApplicationFirewall/socketfilterfw – -unblockapp /Applications/eduVPN.app/Contents/PlugIns/TunnelExtension-macOS.appex - If there is no rule yet, add one:
/usr/libexec/ApplicationFirewall/socketfilterfw – -add /Applications/eduVPN.app/Contents/PlugIns/TunnelExtension-macOS.appex - Optionally also allow the main eduVPN app:
/usr/libexec/ApplicationFirewall/socketfilterfw – -add /Applications/eduVPN.app/Contents/MacOS/eduVPN
On managed devices, we recommend pushing these firewall allowances via your MDM (e.g., a Jamf policy or configuration) so they persist across OS updates and device enrollments.
Note: some browsers may render a double “n” dash as a long “m” dash. For clarity we have added a space between the “n” dashes as – – this space needs to be removed if copy and pasting these command lines.
What we learned
- The symptom is intermittent and often appears after sleep/wake.
- It only affects managed macOS devices with “Block all incoming connections” enabled.
- The macOS Application Firewall (socketfilterfw) is the component enforcing the block.
- Adding an explicit ALLOW for the eduVPN Tunnel Extension resolves the issue while keeping the stricter firewall posture.
We’ll continue to monitor this behaviour and share updates. If you still experience connectivity issues after applying the allow rules, please collect eduVPN client logs and relevant system logs right after a failed wake and contact eduVPN GÉANT support team.
We will also have a bug report with Apple so that this strange behaviour can hopefully be resolved.