"No Connectivity to the proxy server" error
search cancel

"No Connectivity to the proxy server" error

book

Article ID: 402160

calendar_today

Updated On:

Products

Web Isolation Cloud

Issue/Introduction

Customers are having the "No Connectivity to the proxy server" error and also claim that this is a general issue with Fireglass.

In a case study, the customer confirmed that they have identified a potential root cause within the firewall, linked with possible asymmetric routing challenge - incomplete 3-way handshake.

When traffic is routed asymmetrically, as in only one direction traverses the edge and the other direction of traffic does not, this can cause the edge to only see the first SYN in the TCP three-way handshake and will not see the SYN/ACK reply.

Environment

Web Isolation Cloud

Cause

Findings

  • The packet capture shows repeated TCP retransmissions of a FIN, ACK packet from x.x.x.x (ProxySG VIP) to y.y.y.y (Web Isolation tenant at xxxxxxxx.prod.fire.glass).

  • The packet is consistently not acknowledged by the destination, which causes the TCP stack to retransmit.

  • This usually indicates the destination did not receive the packet or cannot respond to it - possibly due to:

    • Asymmetric routing, where return packets from the Web Isolation service are routed differently and do not reach the sending ProxySG.

    • A stateful network device (firewall, NAT, etc.) on the return path discarding the response because it didn't see the initial SYN (thus considers the response invalid).

  • You mentioned intermittent failures - this reinforces asymmetric routing as the likely culprit: depending on the ProxySG handling the request, return traffic might route differently and fail only when that return path breaks symmetry.

Supporting Symptoms

  • Intermittent health check failures on the Proxys for the Web Isolation destination.

  • No TCP response (SYN-ACK, RST, or ACK) from the destination IP.

Resolution

Recommended Troubleshooting Steps

  1. Confirm return path symmetry for each Edge SWG (ProxySG) appliances in the VIP:

    • On each Proxy, run tcpdump (PCAP) and monitor if any return traffic from y.y.y.y (Web Isolation tenant at xxxxxxxx.prod.fire.glass) is received when issues occur.

  2. Check firewalls/load balancers/NATs:

    • Identify if any middle devices are stateful and could be dropping asymmetric return traffic.

    • Confirm session persistence and NAT consistency per source IP across the symmetric path.

  3. Force symmetry:

    • Implement policy-based routing or ECMP hashing rules on routers/firewalls to ensure return traffic always uses the same egress device.

So adding an additional Proxy to the VIP has no relationship with the problem and what appears to be a non-recurrence of the issue.

Additional Note

The PCAP confirmed the Proxy is attempting proper communication, but due to lack of return traffic (or interference mid-path), the session fails - consistent with asymmetric routing symptoms.