Name resolution issue with Azure AD Firewall Auth / Guest Wi-Fi Captive Portal
I have a FortiGate 100F with a LAN interface (10.1.10.1) that uses the local Captive Portal to authenticate users to Azure AD using SAML 2.0 SSO.
I also have a Wi-Fi Interface (10.1.40.1) that uses the local Captive Portal to authenticate guest users with temporary accounts created in ‘User & Authentication -> Guest Management’.
The Captive Portal FQDN is - captive.local.acme.co.uk
I have setup the FortiGate DNS Server database, created a local.acme.co.uk zone and created two DNS A records for the Captive Portal for this FQDN.
Captive -> 10.1.10.1
Captive -> 10.1.40.1
All appeared to work OK for a few days, but now the DNS resolution is selecting the wrong A record, e.g. 10.1.40.1 is being resolved when trying to connect to the Captive Portal from the LAN interface.
Is there any way to force the correct FQDN to IP Address resolution? Or an alternative way of achieving Azure AD firewall authentication and Guest Wi-Fi on the same FortiGate?
Hi Debbie, thanks for the reply! I've already tried something similar to your suggestion. I created a firewall rule that allowed traffic from the Guest Wi-Fi LAN to the Captive Portal on the LAN network and another from the LAN to the Captive Portal on the Guest Wi-Fi network. The issue is that Captive Portal setting for each network are set on the Interface, therefore when trying to connect to the Guest Wi-Fi it tries to authenticate to Azure AD.
Apologies, I don’t think I’m explaining myself properly.
I can access the Captive Portal on the opposite interface, the problem is it then uses the settings assigned to it! For example, when a guest user with a temporary account tries to connect to the Guest-Wi-Fi network the Captive Portal assigned to the LAN interface tries to perform a SAML 2.0 SSO to Azure AD (for an identity they don’t have). Also, if a member of staff (who does have an Azure AD identity) tries to access the LAN, they are presented with a disclaimer and Guest Login page.
Hopefully this makes sense!
This is the Captive Portal settings assigned to the LAN interface
This is the Captive Portal settings assigned to the Guest Wi-Fi SSID
I've done a bit more testing and it looks like it always resolves the Captive Portal address to 10.1.40.1 (regardless of which interface I'm connecting from. I've also discovered that if I connect from the LAN interface the Captive Portal will eventually authenticate to Azure AD event though it is resolving to the wrong address (although there is a 20-30 second delay before this happens!)
I've been viewing the DNS traffic in Wireshark and it looks like the response from the FortiGate DNS contains both IP addresses -
--------------------------------------------------------- Internet Protocol Version 4, Src: 10.1.10.1, Dst: 10.1.10.23 User Datagram Protocol, Src Port: 53, Dst Port: 54676 Domain Name System (response) Transaction ID: 0x90c6 Flags: 0x8580 Standard query response, No error Questions: 1 Answer RRs: 2 Authority RRs: 0 Additional RRs: 0 Queries captive.local.acme.co.uk: type A, class IN Name: captive.local.acme.co.uk [Name Length: 28] [Label Count: 5] Type: A (Host Address) (1) Class: IN (0x0001) Answers captive.local.acme.co.uk: type A, class IN, addr 10.1.40.1 Name: captive.local.acme.co.uk Type: A (Host Address) (1) Class: IN (0x0001) Time to live: 1 (1 second) Data length: 4 Address: 10.1.40.1 captive.local.acme.co.uk: type A, class IN, addr 10.1.10.1 Name: captive.local.acme.co.uk Type: A (Host Address) (1) Class: IN (0x0001) Time to live: 1 (1 second) Data length: 4 Address: 10.1.10.1 [Request In: 259] [Time: 0.001978000 seconds]
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.