Implicit proxy + Saml (azure) auth oddity

[zer0kbps]

Hi everyone, bit of a niche problem, I have many students working from home with laptops provided by us, they are hard configured to browse by the proxy we have set and they're locked down to keep it that way,  they can browse some times but not all.

• So we have an implicit proxy exposed on the FG's wan interface.
• The proxy is configured to default deny.
• There are proxy policies in place permitting access to Azure for the auth process to succeed which it does
• A default policy is inplace that has the SAML_Group object associated against it to permit the learners access to the web, src=all + SAML_Group, dst=all, security= student-web-filter, Full SSL inspection.
• Clients win11, have the CA cert installed from the gate to their trusted ca stores. 
• A session token is provided to the user post auth with 5 minute timeout.
• The user on their laptop can browse the web to certain sites, but then it suddenly blocks them going from say google to whatsmyip.
• In the logs I can see the successful connections are recorded to the UPN user@domain.com etc
• In the default deny log I can see the connection to whatsmyip being blocked and there being no user registered against that specific connection, in this case whatsmyip.
• the whatsmyip site is in a permitted category on the assigned webfilter.
• Proxy settings place the proxy on port 8080 for both http & s.
• http/s sites are being blocked.

[Jean-Philippe_P]

Hello zer0kbps, 

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, 

[Jean-Philippe_P]

Hello,

We are still looking for an answer to your question.

We will come back to you ASAP.

Thanks,

[Jean-Philippe_P]

Hello again!

I found this solution, can you tell me if it helps, please?

It sounds like you are experiencing issues with user sessions and authentication when students are trying to browse the web through the FortiGate proxy. Here are a few areas to investigate that may help resolve the issue:

1. Session Token Timeout: Since the session token has a 5-minute timeout, it is possible that users are being logged out and thus losing their authentication status. This could lead to the proxy denying access to sites after the timeout. You may want to consider increasing the session timeout duration to allow for longer browsing sessions.
   
   

2. Proxy Policies: Ensure that the proxy policies are correctly configured and that there are no conflicting policies that could be causing the issue. Double-check that the SAML_Group object and the web filter are correctly applied to allow access to the desired sites, including "whatsmyip."
   
   

3. Web Filter Configuration: Although you mentioned that "whatsmyip" is in a permitted category, verify that your web filter settings are not inadvertently blocking access. Check if there are any additional rules or settings that may be affecting access to certain sites.
   
   

4. SSL Inspection: Since you are using full SSL inspection, ensure that the inspection is configured correctly. If the SSL inspection is not correctly handling the traffic, it may cause issues with certain HTTPS sites. Make sure that the CA certificate is installed correctly on the client devices and that there are no certificate errors.
   
   

5. Logs and Diagnostics: Continue to monitor the logs for any patterns or specific error messages that could provide more insight into why the connections are being blocked. It may also be beneficial to enable detailed logging on the proxy policies to capture more information about denied connections.
   
   

6. Network Configuration: Check the network configuration to ensure that there are no routing or firewall rules that could be affecting the traffic flow. Make sure that the FortiGate device can reach the internet without any issues.
   
   

7. Client Configuration: Ensure that the proxy settings on the client laptops are correctly configured and that they are pointing to the correct proxy address and port. Any misconfiguration on the client side could lead to inconsistent access.
   
   

If you've gone through these areas and are still experiencing issues, you might want to consider reaching out to Fortinet support for more in-depth troubleshooting tailored to your specific setup. They can provide additional insights and help resolve any configuration issues you may be facing.

[tylerkelley1980]

I've seen similar behavior when using SAML auth with Azure and Fortinet’s implicit proxy—especially if the session tokens aren’t properly cached or the IdP times out during redirection. Double-check your relay state settings and session timeouts. Also, make sure any inspection profiles aren’t stripping SAML headers. Sometimes a slight mismatch in time sync between FortiGate and Azure AD causes oddities too.

[zer0kbps · Accepted solution]

Hi all, I believe I've resolved this one.

It turns out that we had a dns filter configured on the interface to which the ssid was attached. Even though it was a lite-touch dns filter it's presence appears to screw up the known authenticated connections, presumably the Fortigate maybe matching positively a url in the webfilter one minute and then in the DNS filter the next and loosing the authentication information in the process?

I've since removed the DNS filter from the interface under DNS Servers page, left the web-filter in place on the access policy and as a result, access appears to be working as expected, we don't have a tremendous amount of load on it today but nonetheless it's looking positive with all logged traffic being attributed to the respective user.