Firewall drops traffic due to asymmetric routing on Edge SWG

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

External packets destined for a guest user are traversing the proxy’s WAN interface (e.g., 2.0) rather than the expected LAN interface (e.g., 1.0). This causes an upstream firewall (such as a Cisco ASA) to drop the packets, generating a syslog entry similar to:

%<FW>: Deny TCP reverse path check from [Source_IP] to [Destination_IP] on interface [Interface_Name]

Packet captures show that while the initial TCP three-way handshake occurs on the LAN interface, subsequent packets (such as TCP Window Updates) egress via the WAN interface, creating an asymmetric routing path that violates Unicast Reverse Path Forwarding (uRPF) checks.

Environment

Edge SWG (transparent mode)
Multi-homed environment with separate LAN and WAN interfaces.

Cause

The proxy performs a routing table lookup for return traffic. In transparent deployments where the proxy spoofs the server's IP address, the routing table may direct the return packet to the default gateway on the WAN interface instead of the LAN interface where the client resides. This lack of path symmetry causes stateful firewalls to drop the traffic as a security violation.

Resolution

Enable Return to Sender (RTS) to force the proxy to bypass the routing table and send response packets back through the same interface that received the request.

1. Verify current configuration
   1. run the following command on the Edge SWG CLI:

      # config term
      #(config) show return-to-sender

   2. Check if return-to-sender outbound and return-to-sender overwrite-static-route are currently disabled
2. Enable Return to Sender option
   1. run the following command on the Edge SWG CLI:

      #(config) return-to-sender outbound enable
      #(config) return-to-sender overwrite-static-route enable

Additional Information

As per CLI guide: Return to Sender (RTS) eliminates the need to create static routes by configuring the ProxySG appliance to send response packets back to the same interface that received the request packet, entirely bypassing any routing lookup on the ProxySG appliance