Blocking IPsec without breaking the phone's Wi-Fi Calling

The request always arrives in the same shape: close IPsec at the edge because it carries tunnels nobody approved, and the first complaint comes from someone whose phone stopped making calls over Wi-Fi. Both facts are true at once, and neither one justifies dropping the control. What the firewall needs is a service exception with a named feature, a bounded source, documented destinations and an owner. Five steps turn that into a rule a stranger can review next year.

Name the service before you name the protocol

A desk phone on a SIP service and a handset doing carrier Wi-Fi Calling do not share a network profile, and VoIP as a firewall term describes neither of them. Port and destination data has to come from the vendor or carrier that operates the service, not from a remembered port list belonging to another phone system. That is the difference between a rule protecting a feature and a rule protecting a word.

Apple's service-port reference lists UDP 500 and 4500 for Wi-Fi Calling, which happens to be the exact pair most blanket IPsec blocks drop. Write the feature name into the change record next to those ports. Add the version or date of the reference you used, because vendor tables get edited. A rule that names the service it exists for can be reviewed; one that names a protocol category cannot.

Write the exception as a contract, not a favour

The exception states the permitted feature, the device classes that use it, the transport it needs and the destinations the responsible party documents. It also carries an owner and a review date, because carrier endpoints and handset models change without telling the firewall team. Give the review a person rather than a team name that will outlive the team. Keep the wording specific enough that a stranger could re-derive the rule from the record alone.

Put the exception on the same cycle as the rest of the edge policy, so a carrier that moves a destination or a fleet that swaps handset model is noticed at the review instead of at the next outage. Close the loop with whoever reported the broken calls, since they are the only person who can confirm the fix without reopening the tunnel the block was meant to close. That confirmation belongs in the record too, with a date.

A permanent allowance labelled as a temporary phone fix is indefensible two years later. An allowance tied to an identified service has an expiry that renews on purpose.

Scope the source honestly

Limiting the exception to a managed device segment is materially stronger than opening the protocol for every laptop in the building. If the network cannot identify that segment, write that down rather than implying the rule is device-aware. The cheapest good outcome is reusing a boundary that already exists for another reason, so the exception inherits a control instead of inventing one. Filtering by address is not device authentication, and the change record should not suggest otherwise.

A source address or a hardware address is not proof of a physical handset. Whether either carries meaning depends entirely on the other controls inside that segment. If the argument for the rule rests on a MAC address, check what stops a user from changing it before the rule ships.

Accept what a port rule cannot tell you

Ports identify transport endpoints, not business intent. When an approved calling service and an unapproved tunnel both ride UDP 4500, no port-based rule separates them. A rule that claims to looks precise and is not, which is worse than a rule that admits its own shape. That is a limit of the mechanism rather than a mistake by the person who wrote it.

Say so next to the rule, and pair the exception with whatever enforcement the network does have, such as device management or a destination allow-list. Then express the exception as narrowly as the tool allows, for example with nftables rules that name the segment and the port pair and put the general deny after them:

nft add rule inet edge forward ip saddr 10.40.0.0/24 udp dport { 500, 4500 } counter accept
nft add rule inet edge forward udp dport { 500, 4500 } counter drop

nftables evaluates in order and stops at the first match, so the scoped accept has to sit above the general drop. Reverse the two and the exception silently does nothing.

Validate the feature and the denial

Run the approved validation on an ordinary Wi-Fi call, from the device class the exception exists for, and confirm that an excluded client still fails. Never use emergency calling as a test case under any circumstances. Then inspect the rule that shipped, because a counter stuck at zero is the fastest proof that the exception never matched:

nft -a list chain inet edge forward

Include a reconnect or a network change in the test, and repeat it from a cold start with the phone joining the network rather than already attached. If the counter moves while calls still fail, the problem has left the firewall and belongs with the carrier's destination list.