RADIUS Framed-IP-Address for a Stable VPN Client Address

RADIUS can answer with an address for a given user; whether the tunnel actually receives it depends on the gateway. That gap between returned and honored is where most stable-address plans fail. An attribute in a test reply proves the server can send it, not that the remote-access service applies it. The sequence below checks both halves before the address ends up in firewall rules.

Decide which layer owns the address

Remote-access gateways usually have a local pool, and many can also accept an address from the authentication reply. Which one wins depends on the platform, the protocol and the service configuration, so read the precedence rule for the exact release in use. Where the local pool takes priority, the attribute is decoration and the client still lands on a random address. Write the decision down, including whether a returned value must sit inside the pool range or may fall outside it.

RFC 2865 defines Framed-IP-Address as the address to be configured for the user, and says nothing about any particular gateway's willingness to honor it. Vendor documentation is the authority on precedence, not the attribute definition.

Send a test request and read the reply

Test the server in isolation first, so a missing attribute is not mistaken for a gateway problem. radtest sends one Access-Request and prints the attributes that come back.

radtest alice 'S3cret' 127.0.0.1 0 testing123

Look for Framed-IP-Address in the Access-Accept and confirm the value is the intended one rather than a pool address from a fallback rule. When the attribute is absent, the user entry or the authorization policy is not matching, and gateway tuning cannot supply what the server never sent. Repeat the request while the server runs in debug mode if the reply is hard to trace to a specific rule. Keep the shared secret out of shell history and tickets, because the placeholder above is not a credential.

Confirm the gateway honored the value

A correct reply is only half of the contract. The address that appears on the tunnel interface is the observation that matters, and it is read on the client rather than inferred from gateway configuration.

ip -4 addr show tun0

Compare that address with the attribute from the Access-Accept. A mismatch means the gateway ignored or rewrote the value, which reopens the precedence question from the first section. Reconnect once more, because a reservation that works only on the first attempt usually points at a stale session or a lease still held by the previous connection. Record the gateway release and protocol next to the result, so the next person can tell whether the behaviour is version-specific.

Plan for concurrency and revocation

One username on two devices cannot map to one address unless the gateway tells the sessions apart by something beyond the login. Decide whether the mapping belongs to a person, an enrolled device or a certificate identity, and make that choice explicit in the policy store. Test a second simultaneous client and compare both assigned addresses, since a collision here reappears later as a routing fault. The same care belongs in the revocation plan, because an address reassigned while old firewall rules still reference it turns into an authorization bug.

Stable addressing simplifies rules and logs, but it never proves who generated a packet. Authentication and destination authorization still matter when that address later moves to another session.