IKEv2 Uses UDP 500 and 4500: Which One Carries Data?

Opening UDP 500 in the firewall gets the tunnel to negotiate, and then the connection stops passing traffic. The port list was incomplete rather than wrong. IKEv2 starts on one socket and, in many real deployments, continues on another, while the payload may not be a port at all. Reading the stages in order explains which rule is missing.

Two Ports, Two Jobs

IKEv2 begins with a key exchange on UDP 500, where the peers authenticate and establish a security association for the tunnel. The data path that follows is a separate matter: it can be native ESP, which is an IP protocol number rather than a port, or UDP-encapsulated traffic on 4500. Keeping those apart in a firewall review is the difference between a tunnel that negotiates and a tunnel that works. One socket carries control and the other carries payload.

That is why a rule permitting only 500 produces the most confusing symptom in the whole protocol family: negotiation succeeds and nothing useful follows. The state shows a peer, the log shows an established IKE SA, and the application still times out. The missing permission belongs to a different flow than the one that just succeeded.

Why 4500 Exists at All

Many NAT devices cannot forward a protocol other than TCP or UDP, and some rewrite addresses in ways that break ESP's integrity check. Encapsulating ESP inside UDP solves both problems, at the cost of an extra header and a second port to permit. That encapsulation is the reason the second port exists at all.

Once NAT is detected, IKE itself also moves to 4500 so all traffic shares one path through the translator. A four-byte non-ESP marker distinguishes control messages from data on that socket. The switch is a protocol decision rather than an administrator preference.

Where the Source Port Changes

A translator may rewrite the client's source port, so the tuple seen at the server does not match the tuple on the client. Look at both sides of every NAT hop before concluding that a rule is being ignored. Troubleshooting at the client alone can produce a rule that looks correct and still fails.

MOBIKE-capable implementations can also move to 4500 with no NAT detected, and some deployments force that path deliberately. Seeing 4500 is therefore evidence of a decision, not proof of a home router.

Check Both Flows at Every Boundary

Walk the three boundaries: the client network, any intermediate firewall, and the server. Each needs the flows the deployment documents, not the flows from a post about a different one.

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

The ESP line in a firewall listing is a protocol match, so a port rule never covers it. If the operator uses a custom port, follow the documented configuration on both ends, because a client cannot create a listener on the server by choosing a familiar number.

Record where negotiation stopped and whether a child security association was installed, since that pair separates a blocked path from an authentication or policy error. Then repeat the test with server verification enabled, because reachability is not authentication. That last step separates an allowed port from a trusted peer.