strongSwan vips: asking IKEv2 for a virtual address

vips requests an inner IKEv2 address; the gateway decides what to grant. Configure the ask, load it, then verify what the responder actually assigned.

Your IKEv2 client can ask the gateway for an inner address, and the gateway decides what to hand back. In strongSwan that request is the vips setting, and it stays a request even when you write a specific address into it. The runbook below configures the ask, loads it, and reads what came back, because those three steps fail in three different ways. None of them gets shorter by typing harder.

What vips asks for, and what it cannot promise

vips belongs inside a connection definition and asks the responder for a virtual address. The strongSwan virtual-address guide is explicit that the reply can be a different address, or nothing at all, which is the sentence people skip when they write a value and expect it to appear. The request is still worth making, because the answer is what you verify. Treat the setting as an instruction to ask, not as configuration of the outcome.

Requesting 0.0.0.0 asks for any available IPv4 virtual address, which is usually right when the exact value does not matter. Asking for a specific address is a hint to the gateway, not a demand on it.

The swanctl fragment and where it belongs

The setting sits inside the connection block, not in its own file and not in an operating system profile. This isolated fragment shows the shape:

connections {
  net {
    local_addrs = 192.0.2.10
    remote_addrs = 203.0.113.5
    vips = 10.77.0.31
    children {
      net { local_ts = dynamic remote_ts = 10.77.0.0/24 }
    }
  }
}

Load it with the file that owns the connection, then initiate and read the result. A fragment pasted into the wrong section produces a parse error or, worse, a connection that loads without the request you thought you made. Run the three commands in sequence and keep the output.

swanctl --load-all --file /etc/swanctl/swanctl.conf
swanctl --initiate --child net
swanctl --list-sas

local_ts selects traffic, it does not create an address

local_ts names the set of traffic the child SA protects; it does not put an address on an interface. Once a virtual IP is negotiated, strongSwan stops using its default dynamic selector and uses the granted address instead. Pin the selector to a literal address and you are asserting something the gateway may not have granted, which is why the failure shows up as a working SA with traffic going nowhere. The selector describes traffic, while the assignment comes from the other exchange.

The other way to get a stable inner address is to own it locally. Put the address on an interface before the tunnel comes up, point the selector at what already exists, and arrange the peer and the route around it.

Nothing is negotiated in that design, so nothing can be reassigned, and that is the trade: determinism in exchange for doing the addressing work yourself. It is a different mechanism rather than a variant of vips, which is why the two should not be mixed in one connection. A pinned selector beside a negotiated address is a connection that works until the gateway hands out something else.

Verify what the responder actually assigned

Read the SA listing for the address the gateway granted, then confirm that the address exists on the interface. If the two disagree, the tunnel is up and the traffic is not going where you think. A granted address that never reaches the interface is the most confusing failure in this sequence, because each half looks correct on its own.

Keep four addresses apart in your notes: the requested inner address, the granted one, the machine's LAN address, and the public exit a website reports. They belong to different layers and appear in different places. A runbook that records all four is one somebody else can follow without asking which address you meant. Read them back after every reload, since the granted value is the only one that describes the live tunnel.

Keep the static design separate

If you need a fixed inner address, arrange the reservation on the gateway and leave the client request as a request. Mixing a pinned selector with a negotiated address gives a connection that works until the gateway assigns something different. Write the reservation rule down next to the connection, because it is the part a colleague cannot infer from the config file. Then a new client inherits the rule instead of rediscovering it.

On the built-in Mac client none of these option names exist. Use whatever assignment or reservation the gateway offers and the profile the operator publishes, and treat any client-side value as a hint until you have read the assignment back. Rollback is removing the vips line and reloading, which returns you to whatever the gateway assigns by default.

Artaigilean co-cheangailte