Skip to main content

Check out Interactive Visual Stories to gain hands-on experience with the SSE product features. Click here.

Skyhigh Security

Troubleshooting Next Hop Proxy Issues

  1. Last updated
  2. Save as PDF

Overview

If you've configured Web Gateway to use a Next Hop Proxy (NHP) to handle some of your web traffic, you might have seen some dashboard alert warnings indicating that the NHP is down or connection to it has failed. In many cases, when these alerts are triggered, the NHP you have configured is not actually down. For instance, even though the NHP ias still reachable and is passing web traffic, the Web Gateway can mark the NHP as down for additional reasons, such as when the NHP is not able to process a single request from the Web Gateway in a timely manner---this type of issue can be difficult to troubleshoot.  Also, while the NHP is reachable and is passing web traffic, perhaps you notice that browsing slowness occurs in conjunction with the dashboard alert warnings.

The purpose of this article is to give you guidance in the event these dashboard alert warnings occur frequently while evident that the NHP is still online and handling traffic or in the event that slowness occurs in conjunction with the warnings.

Alerts

There are two dashboard alert warnings related to NHP problems.  The warnings below are triggered when the Web Gateway detected that some type connectivity issue occurred with the NHP.  Which warning you observe is dependent upon how the Web Gateway's NHP 'After final failure wait' setting is configured (configuration recommendations are covering in the next section).

  • "Next hop proxy 10.44.44.44 has been marked as down for 10 seconds": This message is displayed if the 'After final failure wait' setting is configured to wait 10 seconds before attempting to re-connect to the NHP, in the event that it had been previously marked as down.
    clipboard_e3e99d164cca8697d21a8f5e3cb86d5b7.png
  • "Connection to next hop proxy 10.44.44.44 failed": This message is displayed if the 'After final failure wait' setting is configured to not wait (0 seconds) before re-connecting to the NHP, in the event that it had been previously marked as down.
    clipboard_ea7d6193ce64025b83f3c8312a3eb2d61.png

Common Scenarios

Slowness experienced due to the next hop proxy being marked as down

NHP Connection Behavior settings

The most common reason for slowness associated to these warnings is due to the 'Number of retries' and the amount of wait time 'After final failure wait' configured for the NHP engine settings. For instance, if Web Gateway were to mark the NHP as down due to a false positive (you've confirmed that the NHP is indeed up and handling traffic), configuring a higher wait time would introduce delay to your user's requests until Web Gateway re-connected to the NHP again.

  • Number of retries. In the event Web Gateway marks the NHP as down, this configures the amount of times the Web Gateway immediately retries to connect to it before quitting. After the final failed retry, the Web Gateway will not attempt to reconnect to the NHP again until after the wait time value below has been reached.
  • After final failure wait. (the wait time) the amount of time you've configured the Web Gateway to wait before it attempts to reconnect to the NHP again. This occurs once the configured 'number of retries' has been reached.

To troubleshoot a slowness problem, we recommend setting the Number of retries to '3' and the After final failure wait to '0', to ensure that Web Gateway does not introduce extra delay even if it detects that the NHP is down.

NOTE: This will NOT stop the warning from appearing in the dashboard, but will help eliminate any slowness introduced by the Web Gateway while waiting to reconnect to the NHP.

clipboard_e30e9639abd48c520a1db5448fcb37173.png

GTI TrustedSource Cloud look-ups

One other potential source of slowness is GTI cloud look-ups which are not configured to utilize the NHP. As part of your default URL filtering and Gateway Anti-malware rules, Web Gateway is configured to go to the cloud for categorization if the local database cannot find a category for a given URL.   When these cloud look-ups are enabled, but it's Next Hop proxy settings are not configured, the attempts to go to the cloud may fail--resulting in end users noticing slowness due to Web Gateway's inability to reach the Skyhigh Security cloud severs. To check your  Next Hop proxy settings for these cloud look-ups, go here:

Policy > Settings > Engines > URL Filter > Select your appropriate URL filter engine > Advanced Settings > Proxy Settings

next_hop1.png

Slowness is not a concern, but the dashboard still indicates the Next Hop Proxy is getting marked as down

NOTE: You might not be able to follow this best practice depending on the Secure Web Gateway (SWG) release that you are working with. The Status codes of healthy next-hop proxy (CONNECT requests) option that it relies on has been removed and is not included in the latest releases of SWG.

As mentioned earlier, these warnings are very difficult to troubleshoot. In many cases, we've seen HTTPS CONNECT requests commonly trigger these warnings. One reason SWG could mark the NHP as down is if the SWG made an HTTPS request (CONNECT) to the NHP, but received a response code back that SWG associates with an unhealthy Next Hop proxy.

To determine whether your warning is a result of this behavior, you can modify the SWG's list of  "Status codes of healthy next hop proxy (CONNECT requests)".  As a test, we recommend setting this to * to diminish any chance that an unexpected status code is causing the alerts you see in your dashboard. You can find this setting under "Configuration > Proxies >Advanced Settings > Status of healthy next hop proxy (CONNECT requests)".

next_hop2.png

If the dashboard alerts disappear after making this change, you know that the problem is due to the NHP responding with a status code not listed in the list above. To determine the status code triggering the warning, a packet capture would need to be taken while a new alert was generated. If assistance is required for further analyzing the data or if the alerts do not stop after making this change, please open a case with technical support.

NOTE: The default status codes SWG uses is: 200, 400, 403, 404, 502, 503, 504

Other Useful Reminders

In Web Gateway deployments using next hop proxies, the following is another commonly overlooked area where a NHP should be configured.

Update Server Setting

When the Web Gateway connects to the Skyhigh Security hosted update servers you will also need to configure your next hop proxy settings in order to successfully obtain your URL, AV, etc updates.  This setting is located in Configuration > Central Management > Automatic Updates > Update Proxies.
next_hop3.png

  1. Back to top
  • Was this article helpful?

Recommended articles

  1. Article type
    Topic
  2. Tags
    This page has no tags.