Cannot connect to saml.threatpulse.net:8443 when using explicit over IPSEC access method with SAML authentication

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Users accessing internet via Cloud SWG using both WSS Agents and Explicit over IPSEC access methods.

All users must authenticate using SAML.

All WSS Agent users can successfully authenticate via the SAML IDP server and browse successfully.

Users accessing services over IPSEC are never redirected to the SAML IDP server to login; instead they are correctly redirected to the Cloud SWG SAML SP, but get following connectivity error on the browser.

PAC file pushed down to browsers indicating traffic should be sent to Proxy at 199.19.250.205:80.

There are no firewall rules blocking TCP port 8443, and a manual telnet from the browser host to 199.19.248.205 port 8443 connects fine.

Bypassing saml.threatpulse.net domain from being proxies seems to workaround the issue.

Environment

IPSEC with Explicit Proxy enabled on browsers.

SAML Authentication.

UPE Managed Cloud SWG tenant.

Cause

DNS restrictions pushed out to Cloud SWG policy.

Resolution

Disable DNS restrictions on reference server, or add exemptions for saml.threatpulse.net. In customer case, DNS restrictions were needed for on-premise setup where ProxySG was placed in DMZ with a DNS server, so we had to add exemption for saml.threatpulse.com.

restrict dns
  list_of_restricted_domains
 except
  saml.threatpulse.net
end

A longer term solution is planned on the Cloud SWG side where DNS restrictions pushed to reference Proxy server will not be pushed into the Cloud.

Additional Information

PCAPs on workstation showed that the CONNECT request from browser to saml.threatpulse.net:8443 would fail an SSL handshake - no server_hello response to the client_hello().

PCAPs on Cloud Proxy showed that we were trying to go upstream to the saml.threatpulse.net Web server that failed.

Since we could not reproduce the issue in our test setup, we managed to get clear difference between the working and non working policy traces; working showed that the proxy handled the request with SAML_realm service, but non working indicated that it was picked up incorrectly by trans-proxy service (and hence tried to go upstream to OCS).

The DNS restrictions showed the DNS lookups were restricted. When restricted, the Proxy policy evaluation cannot resolve DNS and caused the issue.

// working from test setup
 
connection: service.name=SAML_realm_service client.address=10.0.200.3 (NAT address=10.144.102.168) (effective address=10.0.200.3) proxy.port=80 source.port=49872 dest.port=80
client country= pcid=1023
  location-id=xxxxxx access_type=firewall_fqdn_psk_vpn
time: 2023-09-27 16:47:26 UTC
CONNECT tcp://saml.threatpulse.net:8443/
  DNS lookup was unrestricted
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36
user: unauthenticated
authentication status='cannot_redirect_connect' authorization status='not_attempted'
user: authenticated=false authorized=true relative username=''
 
// NOK from customer side
 
connection: service.name=Trans-Proxy client.address=10.107.130.148 (NAT address=10.128.100.14) (effective address=10.107.130.148) proxy.port=80 source.port=57885 dest.port=80
client country= pcid=1023
  location-id=xxxxxx access_type=firewall_fqdn_psk_vpn
time: 2023-09-27 14:35:19 UTC
CONNECT tcp://saml.threatpulse.net:8443/
  DNS lookup was restricted
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0
user: unauthenticated
authentication status='cannot_redirect_connect' authorization status='not_attempted'
user: authenticated=false authorized=true relative username=''