network_not_allowed message accessing any URL via Cloud SWG
search cancel

network_not_allowed message accessing any URL via Cloud SWG

book

Article ID: 241798

calendar_today

Updated On:

Products

Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Users accessing Cloud SWG via IPSEC tunnel.

IPSEC tunnel is up and exchanging data.

Authentication disabled for initial testing.

Users accessing any URLs via IPSEC tunnel get a "network_not_allowed" request error as shown below:

Environment

IPSEC.

PAC files.

Cause

PAC file pushed out to users, which sends traffic to the Cloud SWG data center VIP on TCP 8080 and not the trans-proxy endpoint at 199.19.250.205:80.

Resolution

Change PAC file settings pushed down to users from going to the WSS data center VIP to the trans-proxy IP address / ports defined (199.19.250.205 - 199.9.250.214 on TCP 80) 

The WSS IP address KB article outlines the Ingress IP address for IPSEC and Trans-proxy access methods to be the data center VIP, but technically trans-proxy users must point their proxy settings to be the 199.19.250.205-199.19.250.214 Ip address range only.

Additional Information

When replicating the issue, we could see the following HTTP access log entry when issue occured

2022-05-16 14:04:15 "DP3-GAEAD1_proxysg3" 268 192.168.88.131 - - network_not_allowed PROXIED "Technology/Internet" https://portal.threatpulse.com/ 0 TCP_DENIED POST - https portal.threatpulse.com 443 /djn/directprovider - - "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.160 Safari/537.36" 192.168.3.86 16231 1070 - - - - - - - - 498274 "Location" firewall_vpn "Symantec Web Security Service" - 35.245.151.224 "United States" - - - - - none - - - - none - - ICAP_NOT_SCANNED - ICAP_NOT_SCANNED - - "United States" - "Invalid" 2 - - - - - - - - - - - SSL_Intercept_1 - - - "XMLHttpRequest" #:#:#:#:#:#:#:# xxxxx-xxxxxx-xxxxxx - - "Invalid" "Invalid"

When running a policy trace during replication, we could see the network_not_allowed EXCEPTION was triggered by the following guard

        <Proxy@service-req Transproxy-misconfiguration-guard> [layer 17] [local:201]
 MATCH:         http.method=CONNECT force_exception.request(user_defined.network_not_allowed) 

This guard assumes that the explicit requests from users going through an IPSEC tunnel hits the transproxy endpoint, and not the IP address of the data center VIP itself.