This Article describes the HTTP traffic issue, due to the communication error with the Websense server.
As a result of the HTTP performance issue, the following error message was generated:
2011-01-02 00:55:15 system alert 00014 Communication error with Websense server[10.103.2.59]: SrvErr(0), SockErr(1),Valid(0),Connected(0)
This might be a result of increased communication traffic between the firewall and the Websense server, due to the improvement in the URL Filtering redirect feature.
- With HTTP1.1, pipelining websites can host multiple URL categories on the same server.
- The first URL request is passed to the Websense server. The subsequent requests in the same connection are treated in the same category as the first one.
- However, this is not a bug; as per HTTP1.0 behavior, there can be only one request in the connection.
- The change, which was introduced in ScreenOS 5.3, is to scan every URL request (by sending it to the Websense server) on each HTTP connection.
- This can increase the traffic between the Websense server and the firewall; but should not be an issue with the high-end Websense server.
When there are throughput issues (such as delay), you can disable the feature for the Websense server, which makes the decision on the first request in the packet. The following setting can be attempted; it turns on the flag to undo the above mentioned change in the code:
FW(M)-> set url scan-first
FW(M)-> get config | inc scan-first
set url scan-first
To return to the default behavior:
FW(M)-> unset url scan-first
In certain environments, increasing the number of sockets for communication between firewall and Websense server might also help. However, the number of sockets that are added should be selected with caution; so that it does not affect other TCP connections. First, check the output of
get tcp and then decide the same, based on available TCP sockets.
For example:
if the output shows Total sock: 7/256, this means that only 7 out of 256 sockets have been used. You can try to increase the number of sockets (by default it is 8 and the current number of sockets that are set can be seen in the output of get url) via the following command:
FW(M)-> set url sock <number>
In certain scenarios, you might notice a lot of errors, which are related to the communication between FW and the server over the sockets created between them. Eventually, the communication stops and the status of the server is shown as down; even when the server is reachable from the FW.
- This occurs, if none of the sockets in the socket pool are working.
- The blocking module keeps on trying to make new connections to the server.
- For each non-working socket, the blocking module sends a SERVER_STATUS_REQUEST, every minute.
- It should not be confused with the timeout value provided in get url, which is the server timeout value for no response received during a health check.
- If server can still respond, but is not functioning for some reason, it sends an error code.
- This issue might be related to TCP zero window probe mechanism, which has been fixed/implemented in 6.3 firmware.