Skip to main content
helpdeskBuff
helpdeskBuff
New Member
June 19, 2026
Question

Change Captive Portal IP Interface - doesn't work - Azure SAML

  • June 19, 2026
  • 2 replies
  • 28 views

Hi everyone,

I'm trying to change the redirect IP address of the authentication portal on a FortiGate running version 7.4.12.

I currently have a captive portal that intercepts user traffic and authenticates users via SAML with Entra ID.

The issue is that after changing the IP address under:

 
FGT_1 (auth-portal) # show
config firewall auth-portal
    set portal-addr "10.0.0.1:1003"
end

and, of course, updating the SAML configuration on both the FortiGate and Entra ID, when a user tries to log in using the new IP address (10.2.0.1), the FortiGate redirects them to:

 
https://10.2.0.1:1003/fgtauth

However, the connection just times out, as if port 1003 isn't listening.

If I switch everything back to the original IP address, the authentication works normally again.

I inherited this firewall already configured this way, so I'm not sure if there's another setting I should be checking.

Has anyone experienced this before or knows what else I should look at?

Thanks in advance!

    2 replies

    christian_89_
    christian_89_
    Explorer II
    June 19, 2026

    The timeout is the clue, and this is not a SAML problem. SAML never gets a chance to run, the TCP connection to the portal address fails first.

    The key thing about portal-addr: it only sets the string the FortiGate redirects users to. It does not create a listener. The FortiGate listens on TCP/1000 and 1003 for the captive portal only on interfaces where captive portal is enabled, and the listener binds to that interface's own IP. The redirect URL has to point to the FortiGate interface IP facing the client's captive portal network, which is typically the client's gateway IP. So your original IP worked because it was the client-facing interface IP with captive portal enabled. 10.2.0.1 is almost certainly not that, so the redirect lands on an address where nothing is listening, and the browser hangs on https://10.2.0.1:1003/fgtauth. FortinetCadgulf

    Check these, in order:

    • Is 10.2.0.1 actually an IP on a FortiGate interface? show system interface | grep 10.2.0.1. If it is not a local interface IP, that is the whole problem.
    • If it is a local IP, is captive portal (Security mode set to Captive Portal) enabled on that exact interface? The listener only comes up on captive-portal-enabled interfaces.
    • Can the client even route to 10.2.0.1 and reach it on 1003? From a client on the captive portal subnet, try a plain TCP test to 10.2.0.1:1003. No SYN-ACK means listener or routing, not auth.
    • Confirm the port matches: show full-configuration system global | grep auth-https-port. It should be 1003 to match the :1003 in your portal-addr. If someone changed auth-https-port, the listener is on a different port than your redirect.
    • On the box, sniff it: diagnose sniffer packet any 'host <client-ip> and port 1003' 4 while a user triggers the portal, and see whether the SYN arrives and whether the FortiGate answers.

    The fix depends on what you actually want 10.2.0.1 to be:

    • If you just want to move the portal to a different existing interface, set portal-addr to that interface's IP, and make sure captive portal is enabled on it and the users' subnet uses it as gateway or can route to it.
    • If 10.2.0.1 is meant to be a new portal address, assign it to an interface that faces the users, enable captive portal on that interface, and make the client subnet route to it. The IP has to live on a captive-portal-enabled interface, it cannot be an arbitrary address.

    Two things worth doing properly while you are in here, given this is SAML over HTTPS:

    • Use an FQDN rather than a raw IP for portal-addr. It must be an FQDN that resolves to the interface IP of the captive portal interface, and the client has to resolve it via the DNS server handed out in that subnet's DHCP scope. With a raw IP you also get certificate warnings, since the auth-cert will not match. Set auth-cert to a cert matching the FQDN. Htstone
    • If you want the portal address to be stable and independent of any single data interface, the clean pattern is a loopback interface with captive portal enabled, point the FQDN at the loopback IP, and exempt that loopback IP from captive portal authentication. On 7.4 you can also set the portal address per interface with auth-portal-addr instead of the single global one. Amazon Web Services
    CFR_
      funkylicious
      SuperUser
      funkylicious
      SuperUser
      June 20, 2026

      have you changed the settings under , config user saml , also ?

      L.E. just saw that you said that it has been done.

      try a show full | grep -f 10.2.0.1 , to see where it might have been forgotten

      "jack of all trades, master of none"
      Terms & ConditionsAccessibility statement