Debugging IPSec Tunneling

IPSec Troubleshooting - Basic

When debugging IPSec tunneling, look out for:

1. If you have bi-directional traffic via ESP or NAT-T then the appliances are trying to establish an IPSec tunnel. 
   • Silver Peak Recommendation: Set the MTU size to 1400 to account for IPSec overhead.
2. Another common scenario occurs when another device appliance responds to IPSec requests, rather than the Silver Peak. If you encounter tunnel connectivity issues, it may be necessary to validate the IPSec response is coming from the correct Silver Peak appliance.  If this is found to be happening, most firewalls have an IPSec pass-through feature that can be enabled to get around this.
3. A third scenario to be aware of is the case where no IPSec devices are responding to IPSec requests from the Silver Peak appliance.  This scenario could be caused by a misconfiguration of the pre-shared key or IPSec setup.  It could also be caused when the IPSec requests are blocked by a firewall or other device somewhere between the Silver Peak appliances.

IMPORTANT: If you’re not familiar with IPSec or comfortable troubleshooting using a CLI , we recommend that you involve your network or firewall administrator for assistance in troubleshooting connectivity issues. Making changes to routers, firewalls, and other devices in production environments can cause disruptions in service.

IPSec Troubleshooting – Advanced

Broadcast CLI

Silver Peak Orchestrator provides the Broadcast CLI (BCLI) tool that enables administrators to issue CLI commands centrally from the Orchestrator interface. The BCLI can be used to issue commands to one or many appliances at a time. As long as the Orchestrator can communicate with remote appliances, Broadcast CLI can be used to issue commands for troubleshooting IPSec.

Broadcast CLI can be accessed on the Orchestrator by choosing Maintenance > [Tools] Broadcast CLI

To identify if another device is responding to IPSec requests:

1. Use the BCLI to issue the following command on the remote silver peak: 

   (Tunnel name in this example is tun1. Replace tun1 with appropriate tunnel name in your environment.)

    

   BRSUPP86 (config) # show int tunnel tun1 ipsec status
   Tunnel tun1 ipsec state
     Tunnel Oper:         Down

    

   IPSec Enabled:       yes
     IPSec Oper:          Healthy
     Total IPSec SAs:     in:1 out:1**  
     IPSec Key Size:      256 bits
     Replay Window(bits): 1024

    

   NOTE: 1 SA (security association) sent (out) and 1 SA received (in), but we can’t validate which device responded to our SA.

2. Issue the following command from the BCLI:

    

   BRSUPP86 (config) # show int tunnel tun1 ipsec debug

    

   IPSec stats for tid 2
   -----Key-management---
   Current state: 2
   Req key by dp: 1
   Rekey dp: 0
   Rekey TO: 0
   Rekey # in pkts: 0
   Rekey # out pkts: 0
   Key wait TO: 0
   Passive key TO: 0

    

   -----In-bound---
   Total packets: 0**

    

   Aligment: 0
   No sa: 0
   Verify fail: 0
   Replay check: 0
   Decryption fail: 0
   Other reason: 0

    

   -----Out-bound---
   Total packets: 453
   No sa: 6
   Encryption fail: 0
   Authentication fail: 0
   Other reason: 0

NOTE: “Total packets” should not be 0. This indicates the firewall in front of us responded, and the Silver Peak appliance never got the request. (Scenario 2, above) In this situation, it is necessary to enable “ipsec passthrough” on the firewall. Alternatively, you could elect to connect the Silver Peak appliance directly to the public internet. (Make sure WAN hardening is enabled and proper security precautions are in place.)

 

To validate a deeper issue with IPSec packets traversing the network:

1. If the tunnel debug command shows no SAs at all, you could have an issue with the IKE exchange. This scenario could be caused by a misconfiguration of the pre-shared key or IPSec setup.  It could also be caused when the IPSec requests are blocked by a firewall or other device somewhere between the Silver Peak appliances.

2. Issue the following command from the BCLI:

   (Replace tun1 with appropriate tunnel name in your environment.)

   BRSUPP86 (config) # show int tunnel tun1 ipsec debug

    

   IPSec stats for tid 2
   -----Key-management---
   Current state: 2
   Req key by dp: 1
   Rekey dp: 0
   Rekey TO: 0
   Rekey # in pkts: 0
   Rekey # out pkts: 0
   Key wait TO: 0
   Passive key TO: 0

    

   -----In-bound---
   Total packets: 435
   Alignment: 0
   No sa: 0
   Verify fail: 0
   Replay check: 0
   Decryption fail: 0
   Other reason: 0

    

   -----Out-bound---
   Total packets: 453
   No sa: 6
   Encryption fail: 0
   Authentication fail: 0
   Other reason: 0

The Current State output indicates the ISAKMP key exchange state. For reference, here’s a table of ISAKMP key exchange states as they map to the Current State value:

ISAKMP Key Exchange State	Current State ID
ST_INIT	1
ST_ACTIVE_KEY_WAIT	2
ST_ACTIVE_READY	3
ST_PASSIVE_READY	4

 

If you are stuck in ST_ACTIVE_KEY_WAIT (Current State = 2), then you might have an IKE connectivity problem or a pre-shared-key issue. Check firewall config Check pre-shared key entered correctly If no IKE exchange is happening at all - the SPs (Security Policies) which packets hit to trigger the IKE session may be wrong or missing, due to misconfiguration Check IP address configuration If tunnels come up but we are seeing bad performance Revisit the MTU configuration.  MTU may need to be adjusted lower.