12

Debugging and Troubleshooting

IPsec can be very difficult to debug. In the first place of course it is not possible to capture too much data over the network to see what is wrong, since the first thing the IPsec protocol does is start a Diffie-Hellman key-exchange, guaranteeing privacy. Another issue is that when an IPsec policy is loaded, it prevents any packets from being sent between those machines in the clear. This security feature can be quite annoying to the system administrator who is present on one location, and who is using an SSH connection to configure the other end of the tunnel. The SSH connection will no longer work. Other failures can be the result of intermittent network problems, or even the network architecture.

This chapter aims to help you gather the information needed to diagnose a problem. If you have any doubt about your understanding of IP addresses, netmasks, CIDR notations, and gateways, please read Appendix B.

Do Not Lock Yourself Out!

To prevent losing access to one of your two IPsec endpoints, it is strongly recommended to have access to a third host, that is in no way related to any IPsec policy, and from which you can SSH into both IPsec endpoints. This will prevent you from locking yourself out of your own machines.

Note that if you did not configure Opportunistic Encryption (OE) properly in the DNS, or you forgot to disable OE, you may experience a loss of connectivity for up to 1-2 minutes upon restarting one gateway.

Narrowing Down the Problem

All problems can be categorized into four sections. They are either host system issues, configuration mistakes, network issues, or software bugs. For each type of problem, a different method of gathering information works best.