The ProxySG appliance becomes unresponsive due to a high number of failed authentication requests.

In snapshot_sysinfo_stats, we see that the CW is maxed out, but both the CPU and SW are low, like in the example shown below:

                                                              TM002      HTTP_      HTTP_      HTTP_      HTTP_
                     GMT      CPU0  CPU1  .00.1  MAIN_0090  MAIN_0091  MAIN_0102  MAIN_0111
Wed Dec 14 03:04:41 2011     8    10       35      19500       5430       5414         26
Wed Dec 14 03:05:41 2011     7     9        39      19500       9679       9678         22
Wed Dec 14 03:06:41 2011     8    12       42      19500      12509      12500         21
Wed Dec 14 03:07:41 2011     8    10       43      19500      14259      14253         30
Wed Dec 14 03:08:41 2011     8    15       46      19500      17526      17493         32
Wed Dec 14 03:09:41 2011     4     6         48      19500      19500      19500         30
Wed Dec 14 03:10:41 2011    24    10      48      19500      19500      19500         50

In the eventlog, we see the following entry:

2011-12-14 10:41:18+08:00CST  "LDAP: Server '10.0.5.55' in realm 'AD' is online."  0 26002D:96   ../../realm_ldap.cpp:1093
2011-12-14 10:41:31+08:00CST  "LDAP: Server '10.0.5.55' in realm 'AD' is offline."  0 26002D:1   ../../realm_ldap.cpp:1026
2011-12-14 10:41:31+08:00CST  "LDAP: search failed for base DN:DC=wanda,DC=cn"  FFFFFFFB 260012:1   ../../realm_ldap.cpp:2661
2011-12-14 10:41:31+08:00CST  "LDAP: Server '10.199.200.48' in realm 'AD' is online."  1 26002D:96   ../../realm_ldap.cpp:1093
2011-12-14 10:41:32+08:00CST  "LDAP: search failed for base DN:DC=wanda,DC=cn"  FFFFFFFB 260012:1   ../../realm_ldap.cpp:2661
2011-12-14 10:41:32+08:00CST  "LDAP: Server '10.199.200.48' in realm 'AD' is offline."  1 26002D:1   ../../realm_ldap.cpp:1026
2011-12-14 10:41:32+08:00CST  "LDAP: search failed for base DN:DC=wanda,DC=cn"  FFFFFFFB 260012:1   ../../realm_ldap.cpp:266

In the access log, we see the following entry:

2011-12-14 09:18:57 1 10.49.12.6 - - authentication_failed PROXIED "Computers/Internet" -  407 TCP_DENIED CONNECT - tcp tcpconn2.tencent.com 80 / - - - 10.0.4.5 280 162 -

2011-12-14 09:18:57 2 10.49.12.6 - - authentication_failed PROXIED "Computers/Internet" -  407 TCP_DENIED CONNECT - tcp tcpconn4.tencent.com 443 / - - - 10.0.4.5 280 164 -

2011-12-14 09:18:57 1 10.49.12.6 - - authentication_failed PROXIED "Computers/Internet" -  407 TCP_DENIED CONNECT - tcp update.360.com 80 / - - - 10.0.4.5 280 162 -

2011-12-14 09:18:57 1 10.49.12.6 - - authentication_failed PROXIED "Computers/Internet" -  407 TCP_DENIED CONNECT - tcp up.rising.com.cn 80 / - - - 10.0.4.5 280 162 -

The policy is as shown below:

<Proxy>
    socks.authenticate(ad) socks.authenticate.force(no)

<Proxy>
    client.address=10.0.0.0/8 authenticate(ad) authenticate.force(no) authenticate.mode(proxy-ip)

<Proxy>
   allow

When there are many client software attempts to access the Internet (for an update, query or other purposes), those attempts are asked to provide authentication credentials for Internet access; however, these attempts are transparent to users. In other words, the users won't see the authentication pop up message.

When no credentials are provided, the ProxySG appliance repeatedly asks for credentials which are subsequently blocked. This process repeats until the CW is exhausted.

Analyze the access log, and then add a non-authentication policy at the first layer to bypass this traffic, like in the example shown below:

<Proxy>
    condition=un-auth-grp authenticate(no)

define condition rising

    url.host.exact="rising.com.cn"

end condition rising

define condition 360

    url.host.regex="360.com"

end condition 360

define condition tencent

    url.host.regex="tcpconn[0-9].tencent.com"

end condition tencent

define condition un-auth-grp

    condition=rising

    condition=360

    condition=tencent

    url.regex="tecent.com"

end condition un-auth-grp