Name resolution issue with Azure AD Firewall Auth / Guest Wi-Fi Captive Portal

[MarcusCope]

Hi,

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?

Thanks!

[Anonymous]

Hello MarcusCope, 

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible. 

Thanks, 

Raja- Fortinet Community Team 

[Debbie_FTNT]

Hey Marcus,

I haven't found any way to force a specific hostname to IP resolution on FortiGate, but I am not an expert; perhaps someone else can provide some information.

The only workaround I can suggest is to exempt the IPs in captive portal settings:
- on the LAN interface, exempt the WiFi interface IP
- on the WiFi interface, exempt the LAN interface IP

-> this should make captive portal reachable on both interfaces no matter which IP the hostname resolves to

[MarcusCope]

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.   

[Debbie_FTNT]

Hey Marcus,

that is why I suggested the exemption on the interface itself :)

Basically this:

This allows traffic to the other interface IP to bypass captive portal requirements, and hit the captive portal on the other interface instead.

[MarcusCope]

Hi Debbie,

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

[MarcusCope]

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!)

[MarcusCope]

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]

---------------------------------------------------------

[MarcusCope · Accepted solution]

I've changed the order that the 'Captive' records appear in the Entry table and now 10.1.10.1 is always returned first. 

This works out better for me because the Azure AD firewall auth gets used much more than the Guest Wi-Fi does.

[Debbie_FTNT]

Hey Marcus,

great that you found a solution for yourself :)