Fixed VPN IP: RADIUS Framed-IP-Address or a Pool Reservation

Three places can hold a fixed inner address for a VPN client, and only one of them should own it. RADIUS can return the address in an Access-Accept, the gateway can keep a static mapping for the account, and the client adapter can be set by hand. The first two are policy and the third is a local guess that the gateway is free to ignore or overwrite. Choosing between the first two is the real decision, and it depends on what the network access server actually implements.

Three places a fixed address can live

RADIUS owns the address when the reply carries Framed-IP-Address and the gateway applies that value to the session. The gateway owns it when an administrator maps the account to a static address inside the pool. The client owns nothing, even when its adapter shows a manual address, because the server assigns the inner address during negotiation and a local setting only matters when the server sends none. All three look identical on a working connection, which is why conflicts surface late. The difference shows up on reconnect, on a second device and after a policy change.

Two owners is the configuration that breaks. A RADIUS reply assigning 172.28.4.77 while the gateway holds a static mapping for 172.28.4.90 yields whichever value the vendor's code checks first, and the loser is discarded without a log line. The same account on a second device then receives a duplicate address, and the symptom reads like a routing fault rather than an assignment conflict. Settle the owner before you add the second mechanism.

The client-side option is worth naming only so it can be ruled out. A manual adapter address is a preference the operating system may present, not a reservation, and it cannot stop another session from receiving the same address.

What the RADIUS reply can and cannot promise

RFC 2865 defines Framed-IP-Address as the IPv4 address to configure for the user, and it belongs in Access-Accept. The same attribute in Access-Request is only a hint that the server may ignore, which matters when a client or gateway offers a preferred address. Nothing in the protocol forces the gateway to honour the reply, because the network access server is the component that applies it to the session.

Support is a product question rather than a protocol one. Some gateways apply framed addresses by default, some need a group-level switch turned on before they will, and some accept the attribute and never use it for remote-access sessions. That last case is the dangerous one, because the accounting record can show the reply while the client receives a pool address. Confirm the behaviour on the exact gateway model and firmware you run, not on the documentation for a sibling product.

A reply the gateway ignores looks exactly like a reply that was never sent. Reading the Access-Accept and the session address side by side is the only way to separate the two cases.

Reserve the address inside the pool you already route

Choose the fixed address from the pool subnet that the gateway already routes and that the firewall already trusts. An address outside that range turns a policy change into a routing project, and the VPN will come up while nothing behind it can reply. If per-address access rules exist, add the fixed address to them in the same change.

Decide what a second simultaneous session should do. Assigning one address twice is not device management, and the resulting collision appears as intermittent connectivity for both sessions. Either issue distinct identities per device, issue distinct assignments, or enforce concurrency with a supported check such as Simultaneous-Use rather than hoping the client never reconnects before the old session expires.

Return routes deserve the same attention as the assignment. The gateway needs a route to the pool, the internal routers need a route back to the gateway, and the fixed address inherits both. A single client that works while every other client fails usually means the pool route exists but the host route for the reserved address does not.

Test the reply before you trust the lease

Test the AAA side and the session side separately, because they fail for different reasons. A local radtest shows what the server returns for the account without involving the gateway, and the users file entry shows what the server is supposed to match. Then reconnect the client and compare the address it received with the attribute in the reply.

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

An Access-Accept without the attribute means the server did not match the entry or the attribute was not applied to that user. An Access-Accept with the attribute and a client that still receives a pool address means the gateway ignored it. An Access-Reject sends you back to the credential or the group policy, and none of these outcomes should be debugged by editing the client adapter.

Repeat the check after a reconnect and after a second login from another device. A reservation that only holds for the first session is a pool conflict waiting to happen, and it is cheaper to find now than during an audit.

Pick one owner and write it down

If the gateway applies framed addresses reliably, let RADIUS own the assignment and remove any static mapping for the same account. If it does not, let the gateway own it and remove the attribute from the reply, so the two sources cannot disagree. Keeping both because each one almost works guarantees a future session with the wrong address and no obvious cause.

Write the chosen owner, the reserved address and the pool it came from into the account record. The next person to add a device can then see whether the address is an AAA policy or a gateway mapping before changing either one.