"There was an issue looking up your account" error logging into Azure with SAML on SEP Web and Cloud Access client

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

SAML enabled on Cloud SWG for multiple access methods.

Azure Identity Provider used as SAML server.

Pilot users at a new location cannot browse internet after connecting to Cloud SWG with SEP Web and Cloud Access client in tunnel mode.

Users get the Azure login page rendered but when submitting their email address, the user gets following message rendered in login page:

"There was an issue looking up your account. Tap next to try again"

Azure logs fail to show anything, as it appears that Azure cannot tell who the tenant is based on the email domain, even though it is a valid Azure domain.

Non Azure IDP servers may report different errors but authentication will fail.

Environment

SEP Web and Cloud Access client.

Can also happen with WSS Agent.

SAML authentication to Azure Identity Provider.

PAC file pushed down to Agent to send user traffic to 199.19.250.205:80 (ep.threatpulse.net) on Cloud SWG proxy, but issue happened without any PAC file too.

Cause

Network issue with certain packet sizes, triggered with VxLAN enabled on Wifi AP.

Resolution

A number of possibilities exist :

• Increase MTU size of Wifi interface on firewall, or disable VxLAN that creates additional overhead with WSS Agent UDP packets (if possible)
• Use wssad –p enableUDP=false to force TCP as a transport for the WSS Agent traffic. This requires a client side change.
  • TCP enforces the path MTU algorithm using the IP do not fragment (DF) flag to avoid fragmentation,
• Block UDP 443 on Wifi AP (or internal network) so that we fallback to TCP at transport layer and avoid any issues. This change is the easiest to make, and is the recommended one to carry out.

Additional Information

Looking at the in-tunnel PCAP saved with Symdiag, we identified the TCP connection to login.microsoftonline.com where the users credentials were submitted, and quickly found that the agent would RESET the connection after approximately 20 seconds, and after multiple retransmits of the same data. Looking at the data in more detail, we could see that the server appeared to ACK the highlighted TCP segments below. The re-requested TCP segments that never got answered were for the packets 714 and 716 below, which were both had a length of 1343. Every retransmitted packet of length 1343 towards end of PCAP below never got an ACK.

Packet 720 shows the Cloud SWG Proxy ACKing everything but the missing 1343 length packets - the SACK blocks highlighted are for the TCP segments sent in 715 and 717, but confirms that we have seen everything up to and including TCP segment 713.

Suspecting an MTU issue with the Wifi firewall or after, a few tests were carried out to confirm that confirm this theory:

• Try another network path from inside this office
  • We found an ethernet connection that worked fine; we also tethered laptop to mobile phone and this also worked fine and confirmed problem only happened with WiFI network path.
• Dropped the MTU on the Windows workstation to see of this worked using the following settings - it did!

  • PS C:\WINDOWS\system32> get-NetIPInterface "Wi-Fi"
    
    ifIndex InterfaceAlias                  AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp     ConnectionState PolicyStore
    ------- --------------                  ------------- ------------ --------------- ----     --------------- -----------
    8       Wi-Fi                           IPv6                  1500              50 Enabled  Disconnected    ActiveStore
    8       Wi-Fi                           IPv4                  1500              50 Enabled  Disconnected    ActiveStore
    
    PS C:\WINDOWS\system32> set-NetIPInterface "Wi-Fi" -NlMtuBytes 1300
    PS C:\WINDOWS\system32> get-NetIPInterface "Wi-Fi"
    
    ifIndex InterfaceAlias                  AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp     ConnectionState PolicyStore
    ------- --------------                  ------------- ------------ --------------- ----     --------------- -----------
    8       Wi-Fi                           IPv6                  1300              50 Enabled  Disconnected    ActiveStore
    8       Wi-Fi                           IPv4                  1300              50 Enabled  Disconnected    ActiveStore

• Armed with this information, we went back to Firewall and discovered that it had a VxLAN setup that tunneled Agent UDP 443 traffic within an additional header.
• Edge Firewalls showed that some of the the outbound UDP traffic was being fragmented at the IP layer
  
  // Outbound tunneled Agent traffic visible at time of problem
      
  
  
  // Corresponding PCAPs at Edge Firewall show IP fragmentation occurring for Agent outbound traffic
  
  
• With Agent clusters, every request processed by the NLB requires a port to determine back end service to forward traffic to. In this case, the fragmented IP packet does NOT include a port (destination host re-assembles packet using IP headers) and hence is dropped. This results in authentication failing.