skip to content

In a remote-access VPN, why does the gateway give each client an inner address, and what must the internal network route back to it?

level: middleimportance: should knowfreq 24%

answer

  1. two headers, two source addresses
  2. the hotel address is someone else's
  3. replies must find the gateway
  4. one pool per gateway

basics

~20 s

The inner address belongs to the corporate side, so servers' replies route to the VPN gateway and are tunnelled back; the client's own address belongs to someone else's network. Internal routing must carry each pool prefix to the gateway that owns it.

solid answer

~50 s

A remote-access client sits on a network the company does not control, a hotel, a home router or a mobile carrier, often behind NAT with a private address that may even collide with internal ranges. So the gateway assigns it an address for the session, from its own pool or a DHCP server; IKEv2 does this with the configuration payload (RFC 7296). Each packet then has two headers: the outer source is the laptop's current location, the inner source is the assigned address, and internal servers see only the inner one. For replies to come back, every internal router must route the **pool prefix** to the gateway. With gateways in two data centres, give each its own pool so routing returns each reply to the gateway that holds the session, and size each pool for failover: 2,000 users need at least a `/21`, 2,048 addresses, so a `/20` leaves headroom.

go deeper

for a junior

Recall that a remote-access client gets an address from the VPN gateway, and that internal servers reply to that address, not to the laptop's home or hotel address.

for a middle

Explain outer and inner headers, how the gateway assigns the inner address, and why internal routers need a route for the pool pointing at the gateway.

for a senior

Diagnose the connected-but-silent session, give each gateway its own pool, size pools for failover, and keep pools clear of internal and common home ranges.

for a principal

Treat pool design as part of the address plan for the whole estate, including failover capacity, partner overlaps and how sessions are traced back to people.

## Two headers, two addresses RFC 7296, the IKEv2 specification, describes the remote-access case as an **endpoint to security gateway** tunnel: a roaming computer connects back to its corporate network and, in its words, wants an IP address associated with the security gateway so that packets returned to it go to the gateway and are tunnelled back. Every packet from the laptop therefore carries two source addresses: | Header | Source address | Who routes on it | |---|---|---| | Outer | the laptop's address where it is now, a hotel or home network | the internet, between laptop and gateway | | Inner | the address the gateway assigned for this session | the corporate network, between gateway and servers | The gateway removes the outer header, so internal servers see only the inner address and reply to it. ## Why the client's own address will not do - **It is not routable back.** Behind a home or hotel router the laptop usually has a private address, and the internal network has no route to someone else's private LAN. - **It may collide.** That private address can fall inside a corporate range; a server would then answer a different machine, or itself. - **It changes.** The same user arrives from a new network every day, so policy written against client addresses would never hold. - **It identifies a location, not a session.** An assigned address can be mapped to the session that received it. ## How the address is assigned In IKEv2 the client asks for an address with a **configuration payload** carrying a `CFG_REQUEST`, and the gateway answers with a `CFG_REPLY` containing, for example, an `INTERNAL_IP4_ADDRESS`. RFC 7296, section 2.19, calls the client an IPsec Remote Access Client and the gateway an IPsec Remote Access Server, requires the request in the `IKE_AUTH` exchange, notes that the gateway may take the address from a DHCP server or its own pool, and says the address persists at least until the IKE SA is deleted. Other tunnel designs assign the address by configuration or through their own control channel; the architecture is the same. ## Routing the pool back Follow one request from a laptop assigned `10.250.3.17`: 1. The laptop sends a packet from `10.250.3.17` to a server, encrypted inside a tunnel to the gateway. 2. The gateway decrypts it and forwards it on the internal network with source `10.250.3.17`. 3. The server replies to `10.250.3.17`, handing the reply to its default router. 4. Internal routing must know that `10.250.0.0/20` lives behind the VPN gateway, so the reply reaches it. 5. The gateway matches the reply to the session holding `10.250.3.17` and tunnels it to the laptop's current outer address. If step 4 is missing, the classic symptom follows: the user connects, authenticates and receives an address, and nothing ever answers, because replies follow the default route somewhere else. ## Two data centres, two pools A retailer with 2,000 remote staff and a gateway in each data centre should give each gateway its own pool: | Gateway | Pool | Addresses | |---|---|---| | Data centre A | `10.250.0.0/20` | 4,096 | | Data centre B | `10.250.16.0/20` | 4,096 | - **Distinct pools make return routing deterministic.** A reply for `10.250.3.17` always reaches gateway A, which holds that session. If both gateways shared one prefix, routing could deliver a reply to the gateway without the session, which has nowhere to send it. - **Size each pool for failover.** If one data centre fails, the other must hold all 2,000 users. A `/21` holds 2,048 addresses, barely enough; a `/20` leaves room for growth and for addresses still held by sessions that are being torn down. ## Planning rules - The pools must not overlap any internal, store or partner range. - Avoid the private ranges home and hotel routers commonly hand out, or a user's local LAN can shadow a corporate destination. - Have each gateway announce its pool into internal routing, or point a static route for it at the gateway, so resizing a pool or adding a gateway is one routing change rather than a change on every router. - Include the pools in internal filtering like any other source network. - Record which session held which address and when, since the address is reused once the session ends.

  • How long does an IKEv2 remote-access client keep the address it was assigned?
    RFC 7296 says it is usual to assign one address during IKE_AUTH and that the address persists at least until the IKE SA is deleted. Rekeying the Child SAs under that IKE SA does not change it; a new connection can receive a different one. That is why logs must map an address and a time window to a session, not just an address.
  • Why can a corporate range that overlaps a user's home LAN break the session?
    The laptop has a connected route for its home LAN, say 192.168.1.0/24. If a corporate subnet or the pool uses the same range, the laptop delivers packets for those addresses on the home network instead of the tunnel, so some corporate destinations fail only for users at certain homes. Choosing pools and internal ranges away from common home defaults avoids it.
  • Why not give remote-access clients addresses inside an existing server subnet?
    It can be made to work with the gateway answering address resolution on that LAN for its clients, but it ties every client to one segment, mixes them with servers in filters and logs, and makes failover between gateways awkward. A separate routed pool per gateway is easier to route, filter and fail over.

saying these in an interview costs you the question

  • The client keeps its home or hotel address inside the tunnel
  • Internal servers reply to the laptop's public address over the internet
  • Two gateways should share one pool so users can land on either
  • The pool needs no routes because the gateway is on the internal network
  • Any unused private range will do for a remote-access pool