This article applies to:
Question:
- What is the best way to health-check an SWG Proxy?
Information:
The Health Check mechanism is usually required to ensure that a device is up and available to process User/Server sessions/requests.
There are multiple ways to achieve that with an SWG proxy; For example, it could be an external URL, assuming that the Web Server hosting it is itself available.
In this case, the source device expects to get a predefined response code from the SWG proxy, which is usually HTTP 403 Forbidden code or HTTP 200 OK code.
SWG health-check functionality provides URL(s) that could be used for that purpose, making it easier for administration:
- http://Vital.Security.Health.Check - responding with HTTP 403 Forbidden code
- http://Vital.Security.Loadbalancer.Check - responding with HTTP 200 OK code
Both health-check resources operate equally well for the purpose of actual system monitoring.
However, one important detail should be mentioned about the response code returned by these health checks:
If SWG is set to use a custom Block Page template using enhanced HTML components (form, logo, labels), it may result in a larger Block Page that is
sent back by SWG to the source device.
As a result, the TCP session established for such health check may not be closed properly on the SWG side, as shown in the network snippet below:
SWG proxy 172.18.180.151 sends HTTP 403 Forbidden response (packet #82).
Client, 172.18.180.152, does close it from its side (FIN packet #86); However, SWG proxy does not close the session.
The network snapshot above was taken from an SWG proxy that is sending a custom Block Page with multiple graphical components in it.
(Multiple customers do modify the Blocking Page to make it look more user-friendly or business-oriented.)
The network snapshot below was taken from an SWG proxy set to send a default Block Page, with no graphical enhancements in it:
Same SWG proxy sends HTTP 403 Forbidden response (packet #34) and immediately after that sends FIN packet #35 to close the TCP session from its side.
Same client as in previous example then sends FIN, ACK packet #39 to close the TCP session from its side.
When the SWG proxy returns HTTP 200 OK code it does not send a Block Message (custom or default), which in turn prevents the situation where network
sessions are not properly closed.
We used http://Vital.Security.Health.Check URL in this example, returning HTTP 403 Forbidden code.
Based on these results our recommendation is to prefer the second health check URL: http://Vital.Security.Loadbalancer.Check responding with
HTTP 200 OK code.
Notes:
These test results do not provide solid evidence that the network sessions are not closed properly.
However, it may result in some unexpected situations due to continuous inefficient operation mode.