Who Actually Answers on the VPN's Dedicated Address?

An address sitting unused in the organisation's allocation is not a listener, and adding it to a firewall does not create one. Something has to terminate IKE on that address, and the mechanism differs depending on whether the gateway owns the address or an upstream device translates it. The packet path is what distinguishes the two, and it decides which platform feature you need before anyone opens a change request. Model the path first, then choose.

The packet path behind the address

A peer sends IKE to the address it was given, on UDP 500 or on UDP 4500 when NAT traversal is in play. Whatever device holds that address on the path either receives the datagram locally and answers it, or forwards it somewhere else. Those are the only two possibilities, and everything else in this article follows from which one is true.

Receiving locally means a socket exists on that device, bound to that address. Forwarding means the datagram is rewritten and sent onward to another endpoint, which then has the socket. A firewall rule that permits UDP 500 tells you nothing about which of those is happening.

Write the record before you touch anything: the address peers contact, how the upstream network delivers it, the local interface or logical endpoint that receives it, and the process that answers IKE. Four lines, and each one can be checked. When one of them is unknown, that unknown is the design work rather than an implementation detail to settle later. Filling them in after the change request is approved is how a translation rule gets added to the wrong device.

Model A: the gateway owns the address

In the first model the gateway holds the address itself, either as a secondary address on an existing interface, as an address on a dedicated interface, or as a loopback that the platform supports as a tunnel endpoint. Those are three different features with three different configuration paths, and a platform that supports one may not support the others.

Confirm the platform and release support the exact arrangement before you design around it. A routed block, an additional address on an interface, and a loopback endpoint are not interchangeable, and documentation for one release does not promise the next one behaves the same way.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

The listening socket is the proof. If nothing is bound to the address, the gateway is not the terminator regardless of what the routing table says, and a packet capture will show the datagrams arriving with nothing answering them.

Do not place a second interface into a subnet that already exists elsewhere in the topology and assume the platform will sort it out. Overlapping interface subnets produce ambiguous source selection and, on many platforms, a refusal to configure at all.

Model B: an upstream device translates it

In the second model an upstream firewall holds the dedicated address and forwards the traffic to a different VPN gateway. That is a destination translation with a return path, and it is a perfectly valid design as long as it is documented as one.

What it is not is evidence that the upstream device acquired a local VPN socket. The translation forwards packets; it does not make the upstream box an IKE responder. If the upstream rule is removed or its return path breaks, the VPN stops even though the gateway is healthy and its own listeners are intact.

Record both addresses: the one peers contact and the one the gateway actually sees. Then record the transport and the return path, because a translation that works for UDP 500 but not for encapsulated ESP will connect and then fail to carry traffic, which is a confusing failure to debug later.

Identity is not the outer address

IPsec separates the tunnel endpoint from the traffic it protects, and the architecture keeps those decisions in different places. Changing the address peers contact does not automatically change which inner prefixes are permitted, which routes are installed, or which resources the session may reach.

The authenticated identity is separate again. IKEv2 carries an identity payload and an authentication exchange that need not match the outer packet address, which is precisely why a translated design can still authenticate correctly.

That independence is useful and also a trap. Two DNS names resolving to one ordinary listener do not select different VPN backends, and a certificate that names one identity will not satisfy a peer expecting another. Confirm what the peer validates before you assume the address alone decides it.

Accept the design by watching one connection

Inspect where a fresh authorised connection is actually delivered, which identity answers, and which private flow is then permitted. Three observations, three different layers, and a successful public lookup of the address tests none of them.

Keep the negative case as well: a peer that should not be accepted, or an inner prefix that should not be reachable, verified after the change. The record you wrote at the start is what makes that test possible without reconstructing the design from memory.

The point of all this is to let the network owner choose a supported allocation method rather than relying on a general claim about what every firewall can do with an extra address. That claim is exactly where these designs go wrong, because it sounds plausible on every platform and is true on none of them in general. The four-line record settles it for your platform in ten minutes.