A VoWiFi gateway is an unusual piece of software. Its clients are not browsers or applications you can patch — they are the IKEv2 stacks baked into handset firmware, shipped years ago, and utterly unwilling to negotiate. Whatever the specification says, the device you actually have to serve is the one in your subscriber’s pocket. This update summarises what changed and why it matters if you are planning a rollout.
Devices Interpret the Specification Generously
If there is one lesson from putting an ePDG in front of a drawer full of commercial phones, it is that 3GPP TS 33.402 leaves more room than its authors probably intended. Our IKEv2 implementation now covers the full SWu profile along with the deviations we have seen in practice.
Complete transform set
AES-CBC and AES-GCM with 128, 192, and 256-bit keys, HMAC-SHA1 and SHA-2 integrity, AES-XCBC, and MODP groups up to 4096 bit. This is not thoroughness for its own sake: several device families propose exactly one cipher suite. If it is missing, that device simply never connects, and nothing in the logs tells a casual reader why.
Tolerant where devices cut corners
Some current handset stacks omit attributes their proposals are required to carry. The ePDG applies the sensible default, responds strictly to specification, and logs the deviation. Calls work, and the anomaly stays visible instead of being papered over.
Correct error paths
When a device opens with a Diffie-Hellman group we do not accept, the response now tells it which group to retry with, as RFC 7296 intends. Previously this class of mismatch presented as a mysterious missing-algorithm failure; now it costs one additional round trip and the call proceeds.
Found on hardware, not in a conformance suite
None of the above came out of a test harness that speaks the specification back to itself. They came out of live lab sessions with commercial handsets — the same loop that drives our continuous verification of the rest of the stack.
EAP-Only Authentication: The Blocker Nobody Warns MVNOs About
One finding deserves more than a bullet point, because it decides whether a smaller operator can offer VoWiFi at all.
In the textbook SWu exchange the ePDG authenticates itself to the device with a certificate, and the device authenticates itself with EAP-AKA over the USIM. That works beautifully — provided the handset trusts your certificate. Many handsets, Samsung most prominently, will only accept an ePDG certificate that chains to their built-in trust store. Installing a custom CA on the device does not help; the VoWiFi client does not consult the user store.
For an MVNO, certificate-based IKEv2 can be a closed door
Getting an operator certificate into the trust stores of the major handset manufacturers is a process built around large incumbent carriers. If you are not one of them, no amount of correct configuration will make those devices complete the exchange — and the failure looks like an authentication problem rather than a trust problem.
The way out is RFC 5998: EAP-only authentication in IKEv2. Because EAP-AKA (RFC 4187) is itself a mutually authenticating, key-generating method, the certificate exchange can be dropped entirely. The device authenticates the network through the USIM, exactly as it does on the cellular side, and the trust store never enters the picture. Our ePDG supports this, and it turns the single biggest device-compatibility blocker for smaller operators into a configuration default.
| Certificate-based IKEv2 | EAP-only (RFC 5998) | |
|---|---|---|
| How the device authenticates the network | ePDG certificate | Mutual EAP-AKA over the USIM |
| Required trust anchor | Must chain to the handset’s built-in store | Subscriber credentials in the HSS |
| Custom CA installed on the device | Ignored by many VoWiFi clients | Not needed |
| Usable without an operator certificate | No | Yes |
| Where it is specified | RFC 7296, TS 33.402 | RFC 5998 with RFC 4187 |
A Datapath Built for Production Scale
The ePDG datapath has been redesigned around a shared tunnel interface per instance. Session setup is now pure in-memory bookkeeping: no per-subscriber network interfaces, no per-subscriber routing rules, no shell-outs in the attach path.
That distinction is easy to overlook in a lab with five devices and impossible to ignore in production. A design that creates kernel objects per subscriber gives the host more state to evaluate with every attach. Ours does not: the kernel-side footprint stays constant whether ten or a hundred thousand subscribers are attached.
Attach storms are the classic failure mode of VoWiFi gateways: every device that lost its tunnel comes back at once, and a gateway whose per-attach cost grows with occupancy turns a brief outage into a long one. With a constant footprint, the storm is absorbed.
Address management is deployment-friendly in the same practical spirit. Multiple UE address pools can be configured side by side, IPv4 and IPv6 mixed, so different packet gateways can hand out different ranges. Multiple ePDG instances run active-active on the same host, each with its own isolated network state. And misconfigurations fail loudly at startup: a subscriber whose assigned address falls outside the configured pools is rejected with a clear log line, rather than being silently connected without a working data path.
Restarts Without Dropped Calls
VoWiFi gateways hold long-lived state, and production means restarts, upgrades, and the occasional unexpected failure. A gateway that only behaves well between maintenance windows is not finished.
Established sessions can now be persisted and restored after a restart or failover — and, importantly, restored before new connections are accepted, so a recovering instance is never briefly serving new attaches while old ones are still missing. On the same host, surviving kernel IPsec state is adopted in place. After a move to another host, it is reinstalled from persisted keying material. Phones stay connected through a gateway restart without noticing.
Alongside that, a periodic audit compares kernel IPsec state against live sessions and removes anything orphaned by an interrupted teardown or an abrupt failover. Leftover state stops accumulating silently, and the corresponding metrics make a teardown anomaly visible in monitoring long before it becomes a support case. This is the unglamorous half of operating a gateway at scale, and it is usually the half that decides how a deployment feels after six months.
Deregistration That Reaches the Tunnel
Subscriber lifecycle management is another place where a gateway can look correct and behave wrongly. Removing a subscriber in the HSS should not leave an authenticated tunnel standing.
It no longer does. When a subscriber is deregistered or deleted, the change propagates all the way to the tunnel: the HSS sends a Registration-Termination-Request over SWx, the AAA server correlates it with the active session, and instructs the ePDG over SWm with an Abort-Session-Request. The ePDG tears the tunnel down with an IKEv2 Delete. All of it follows 3GPP TS 29.273 rather than a proprietary side channel.
The AAA server has matured alongside the gateway: full TS 29.273 interworking across SWm, SWx, S6b, and STa, and deliberately HSS-agnostic, so it drops into an existing core without forcing a vendor decision somewhere else. If you want the detail on what happens between authentication and the first SIP REGISTER, that is covered in bearer establishment.
What This Means for Your Rollout
Every item above exists because a real device or a real operational scenario demanded it. None of it would have come from reading the specifications more carefully. That feedback loop — lab finding to released fix in days rather than quarters — is the core of how we work, and it is what we bring to an integration: your device population, your packet core, your operational constraints.
The device population is the requirement document
An ePDG that passes conformance testing and fails on a popular handset is not a working ePDG. Before you commit to a VoWiFi launch, the question worth answering is not whether the gateway implements TS 33.402 — it is whether the phones your subscribers actually carry complete the exchange.
If you are evaluating VoWiFi for your subscriber base, as a standalone service or as the first step toward full VoLTE, we would be glad to show you how quickly a proof of concept can be up and running.
References: TS 33.402 (security aspects of non-3GPP access), TS 24.302 (access to the EPC via non-3GPP networks), TS 29.273 (EPS AAA interfaces: SWa, STa, SWm, SWx, S6b), RFC 7296 (IKEv2), RFC 5998 (EAP-only authentication in IKEv2), RFC 4187 (EAP-AKA), GSMA IR.51.