Technical Tip: Why re-authentication is needed in a IPsec / ZTNA Access environment when a client's IP address changes

Description

This article describes the reasons for re-authentication requests in an IPsec / ZTNA Access environment when client's IP address changes.

Scope

FortiGate, FortiClient, FortiClient EMS.

Solution

In environments where both IPsec VPN and ZTNA Access Proxy are used, frequent changes in the client's IP address can trigger new authentication processes. This behavior is expected due to the following reasons:

1. IPsec VPN authentication:

   • IPsec VPN connections often rely on the client's IP address as part of the session establishment and maintenance process. When the client's IP address changes, the existing session may become invalid, requiring re-authentication to establish a new session.
     

   • For both IPsec and SSL VPN, the firewall tracks sessions using a tuple that includes:

     • Source IP

     • Destination IP

     • Security associations (IPsec) or session/cookie (SSL/ZTNA)

   • When the client public IP changes, from the firewall's perspective:

     • It is not the same client anymore.

     • The existing tunnel/session becomes invalid.

     • A new authentication attempt is required.

     This is not a bug: it is a security design to prevent session hijacking.
     

   • With IPsec:

     • The tunnel is built using IKE (Internet Key Exchange)

     • Security Associations (SAs) are negotiated between two fixed endpoints (IPs)

   • If the client IP changes:

     • The SA becomes invalid

     • The tunnel must be re-established

     • That often means re-authentication (XAuth, EAP, certificates, etc.)

     This is fundamental to how IPsec works, not Fortinet-specific.
     

2. ZTNA access proxy authentication:
   

• ZTNA is even stricter by design. Zero Trust = Never Trust, Always Verify = continuous verification.

• Similar to IPsec VPN, ZTNA Access Proxy may also use the client's IP address as part of its session management. If the IP address changes, the session may be considered invalid, prompting a new authentication request.

• ZTNA does not trust sessions implicitly. It validates:

  • User identity.

  • Device posture (via FortiClient EMS).

  • Source IP / network context.

  • Certificates / tokens.

• So when the IP changes:

  • Context changing means trust must be re-evaluated.

  • Re-authentication may be triggered.
    

3. Security considerations:

• Frequent IP address changes can be seen as a security risk, as they may indicate potential session hijacking or other malicious activities. Re-authentication ensures that the user and device are still authorized to access the network resources.

This is an expected behavior due to security design, not a misconfiguration.

VPN ties sessions to IP -> IP change = new session.

ZTNA enforces continuous trust -> context change = re-validation.

ISP instability amplifies both

In short:

Dynamic IP + Zero Trust + IPsec = frequent re-authentication.