ProxySG bypass vs Magic Script

[JS_2022]

Just curious how the 2 troubleshooting features are different:

Proxy Bypass for single IP:
link - How to bypass a ProxySG or Advanced Secure Gateway in a Transparent environment

Broadcom		remove preview
How to bypass a ProxySG or Advanced Secure Gateway in a Transparent environment Resolution Add the specific IP address of the workstation to be bypassed in the Static Bypass List. From Management Console > Configuration tab > Services > Proxy Services > Static Bypass List tab > Client host or subnet > Enter the client IP Add the IP address of the Destination to be bypassed in the Static Bypass List. View this on Broadcom >

Magic Script:
link - Troubleshoot ProxySG or ASG appliance issues with a specific web site

Is there an advantage to using CPL vs the WebGUI?

[Jacob Miles]

Hi JS,

With bypassing, the ProxySG is not intercepting the traffic at all. In a transparent deployment, we can use the Static Bypass List to bypass. The traffic is "bypassed" from the ProxySG and will go on its normal route as if the ProxySG wasn't there. The advantage of Static Bypass is we can isolate the ProxySG in our troubleshooting without isolating other network components. 

If we use the Static Bypass on the ProxySG, and the network issue still persists, we can conclude other network devices are at play and should be investigated. If we use the Static Bypass and the issue goes away, then we know we need to troubleshoot further on the ProxySG. When using this approach, do be aware of possible ACL policies on other network devices. Some organizations have firewall rules that block traffic that isn't coming from a proxy. As the traffic is unaltered in Static Bypass, traffic reaching the firewall would still have the client IP or the end user computer and not the ProxySG. Verify with packet captures if this is happening.

ProxySG has very robust tools with its packet captures and policy tracing to try and pinpoint issues. The Magic Script is also very helpful as it allows us to easily disable common policy mechanisms that may be failing (SSL decryption, authentication, etc). One could make all the objects in the Visual Policy Manager (VPM), but by having it in CPL, it is easy to comment out a line to reenable some feature for testing, push policy, and continue testing. It is also easier to disable after testing is done. Overall, troubleshooting becomes much faster. 

In an explicit deployment, bypassing using the Static Bypass is not an option as the traffic being received is addressed (destination IP) to the ProxySG. Since the traffic is addressed to us, we do have to touch it in some way, and make a request to upstream server for the client to get their content. It is still possible to bypass the proxy infrastructure by changing a PAC file or proxy settings, but it doesn't isolate just the ProxySG. One therefore cannot conclude the issue is the ProxySG if the issue goes away when the PAC file or proxy settings are changed. I have seen many times where the issue is a partially hung switch or router that otherwise would be missed. For these explicit deployment cases, the magic script is very useful in isolating which ProxySG policies (if any) may be interfering with the desired behavior. 

I hope that helps!