5.5 Debugging Interception

only for RuBoard - do not distribute or recompile

5.5 Debugging Interception

Many people seem to have trouble configuring interception caching on their networks. This is not too surprising, because configuration requires a certain level of familiarity with switches and routers. The rules and access lists these devices use to match certain packets are particularly difficult. If you set up interception caching and it doesn't seem to be working, these hints may help you isolate the problem.

First of all, does the caching proxy receive redirected connections? The best way to determine this is with tcpdump . For example, you can use:

 tcpdump -n port 80 

You should see a fair amount of output if the switch or router is actually diverting connections to the proxy. Note that if you have an HTTP server running on the same machine, it is difficult to visually differentiate the proxy traffic from the server traffic. You can use additional tcpdump parameters to filter out the HTTP server traffic:

 tcpdump -n port 80 and not dst 10.1.2.3 

If you don't see any output from tcpdump , then it's likely your router/switch is incorrectly configured.

If your browser requests just hang, then it's likely that the switch is redirecting traffic, but the cache cannot forward misses. Running tcpdump in this case shows a lot of TCP SYN packets sent out but no packets coming back in. You can also check for this condition by running netstat -n . If you see a lot of connections in the SYN_SENT state, it is likely that the firewall/ nat rules deny incoming packets from origin servers. Turn on firewall/ nat debugging if you can.

You may also find that your browser works fine, but the caching proxy doesn't log any of the requests. In this case, the proxy machine is probably simply routing the packets. This could happen if you forget, or mistype, the redirect/forward rule in the ipchains / ipfw configuration.

only for RuBoard - do not distribute or recompile