Hi,
The entries in bypass list takes the following forms:
- IP address
- CIDR address such as 10.1.1.0/24
- domain name such as example.com
- hostname such as crm.example.com
(It DOES NOT allow partial hostname such as .example.com, but example.com would match www.example.com if T1 interface is monitoring DNS queries)
In our current implementation of "proxy bypass", this feature only works under transparent deployment.
Meaning, if the HTTP request is explicitly forwarded into the proxy port, "proxy bypass" would not take effect.
Let's say you have example.com in your "proxy bypass" list, and T1 interface is not connected.
In this case, WSA would perform an explicit DNS lookup for example.com (interval is every 30 min) to update its internal cache,
requests going to and from example.com would be "bypassed". But requests going to and from www.example.com would NOT be "bypassed".
Next, if T1 interface is monitoring DNS traffic, any DNS queries with domain of example.com
(www.example.com, mail.example.com ...etc) will be snooped, and it's IP will be added into WSA's "proxy bypass" list.
As a result, HTTP requests to www.example.com WILL be able to bypass the proxy.
So, if you are only using
- an IP address
- a CIDR address such as 10.1.1.0/24
- a hostname such as crm.example.com
It is not required to use T1 interface to snoop DNS queries unless the hostname uses some sort of dynamic IP range. In this case, it is possible that the hostname resolution on the client is different than the hostname resolution on the WSA and the proxy bypass would not match.
When using WCCP, we negotiate against the router that we want to return the forwarded packets. If the packet was forwarded via L2, packets would then be forwarded towards the ultimate destination just like how normal proxy packets would (But please remember that source IP would not be rewritten). If packets are forwarded via GRE, we would send the packets back through the same GRE interface which it came in.
When using L4 switch, extra caution is required to prevent forwarding loops. Switch would forward traffic to WSA, and if the forwarded packet matches what is in its "proxy bypass" list, WSA would forward it back to its ultimate destination. Switch somehow needs to know not to forward those packets back to WSA. Normally this is done by bypassing anything that has WSA's IP as a source address, but in this case source IP is untouched, hence has the real client's IP. Which means the switch needs to be configured not to forward back packets which has the source MAC of WSA's interface.
