A single user cannot browse via Cloud SWG over IPSEC Trans-proxy with SAML authentication

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Users accessing internet via Cloud SWG using IPSEC trans-proxy access method from on premise and remote devices.

Remote users connect to a VPN server where the internet traffic is backhauled into Cloud SWG.

All users except for a single user could browse successfully - this one user could not establish connections to any web servers.

Browser reporting generic connectivity errors when trying to access any site.

PCAPs indicate that TCP SYN requests into the Cloud Proxy are unanswered, for this one host.

Having another user login to the problem host showed similar connectivity errors, so the issue is not user but host specific.

Environment

Cloud SWG.

IPSEC tunnels.

VPN client.

Cause

Assigned RFC 1918 IP address conflicting with one RFC1918 IP address used by Cloud SWG VPN server platform.

Resolution

As a temporary workaround until Cloud SWG changes the IPSEC platform IP address setup, VPN admins made sure that the "192.168.244.24" address was not handed out to any users.

This 192.168.244.24 is used by the IPSEC platform and caused a routing failure to the Cloud Proxy, explaining why the TCP SYN never saw a response.

Additional Information

Looking at the PCAPs taken on the concentrator, we could see user traffic visible on the inbound interface, but never seen on the upstream interfaces towards the proxy as shown here:

14:20:39.863246 eth0  In  IP 192.168.244.24.54811 > 199.19.250.212.80: Flags [S], seq 3984493962, win 23360, options [mss 1383,sackOK,eol], length 0
14:20:40.143028 eth0  In  IP 192.168.244.24.57892 > 199.19.250.212.80: Flags [S], seq 1632210626, win 23360, options [mss 1383,sackOK,eol], length 0
14:20:40.342548 eth0  In  IP 192.168.244.24.57892 > 199.19.250.212.80: Flags [S], seq 1632210626, win 23360, options [mss 1383,sackOK,eol], length 0
14:20:40.554287 eth0  In  IP 192.168.244.24.54131 > 199.19.250.212.80: Flags [S], seq 3278824807, win 23360, options [mss 1383,sackOK,eol], length 0
14:20:40.863339 eth0  In  IP 192.168.244.24.54811 > 199.19.250.212.80: Flags [S], seq 3984493962, win 23360, options [mss 1383,sackOK,eol], length 0
14:20:41.342212 eth0  In  IP 192.168.244.24.57892 > 199.19.250.212.80: Flags [S], seq 1632210626, win 23360, options [mss 1383,sackOK,eol], length 0

Another user in the same tunnel and same subnet worked fine as the logs below show:

14:35:43.898756 eth0  In  IP 192.168.100.242.12107 > 199.19.250.212.80: Flags [S], seq 390220547, win 23360, options [mss 1383,sackOK,eol], length 0
14:35:43.898784 natlo Out IP 192.168.100.242.12107 > 199.19.250.212.80: Flags [S], seq 390220547, win 23360, options [mss 1383,sackOK,eol], length 0
14:35:43.898800 eth1  Out IP 10.128.11.68.12107 > 199.19.250.212.80: Flags [S], seq 390220547, win 23360, options [mss 1383,sackOK,eol], length 0