Wireless Access

What is IPSec ?

IPSec uses DES, 3DES, or AES for encryption.

IPSec uses RSA for IKE internet key exchange for during peer authentication phase, to ensure the other side is authentic and who they say they are.

IPSec tunnel between two devices will be established in two phases.

IKE Phase 1 :

Key Exchange Phase

Establish a secure channel (ISAKMP SA)

Authenticate computer identity using certificates or pre-shared secret 

Secures Phase 2 negotiations

IKE Phase 2 :

Establishes a secure channel between computers intended for the transmission of data (IPsec SA)

Determines encryption and authentication algorithms for user data

Each SA assigned a unique Security Parameter Index (SPI)

Each SA is unidirectional

Both phases create two unidirectional Security Associations (SA). The controller assigns a locally unique Security Parameter Index (SPI) to tag or name that specific entry.

What are the common issues with IPSec ?

• Firewall blocking connections between peers
  • ESP: UDP 50
  • ISAKMP/IKE: UDP 500
  • NAT-T: UDP 4500
• NAT
  • NAT can corrupt ESP integrity check.
  • When used, NAT-T preserves ESP integrity by pre-pending a new IP header as a NAT target
• Mismatched Preshared Key
  • Used in Phase 1. Peers must have same value
• Mismatched Security Parameters
  • IPSec peers must agree on encryption and authentication methods for user data
  • Negotiated during Phase 2

Troubleshooting Flow :

Step 1 : How to confirm, whether NAT-T traffic session is on or not and what is NAT-T traffic ? and both are in sync ?

In many cases, Aruba uses NAT-T (NAT Traversal) to protect the IPSec integrity whenever the tunnel passes through a NAT device.

NATT encapsulates IPSec in a UDP 4500 header.

 Ensure that the controller sees a NAT-T session from the peer using the above command.

• If the peer entry is missing, then ensure that external firewalls are not blocking UDP 4500.
• Ensure that the tunnel map has the correct peer address.
• Ensure the peer address is a routable and reachable IP address between the peers.
• Ensure that 'Y' flag is appearing in both the directions

Step 2 : Confirm whether the VPN pool is present and address are available .

• The tunnel must obtain a Private Inner IP address assigned by the IPSec concentrator
• Ensure the address pools created and free address are available

Step 3 : Confirm whether the SA is successful or not

• Confirm the presence of the isakmp sa using the show crypto isakmp sa command.
• This identifies which peer initiated the connection, and also how the connection was authenticated.
• The Private IP address is the VPN “inner address” assigned by the controller from the VPN address pool.

• View details for the SA of interest by extending the crypto command with the ip address of the peer device.
• This is the “public outer IP address” that is used to route the tunnel across the network.
• You can use this to first ensure that an SA established for that peer.
• This indirectly confirms that the pre-shared key matches.
• If Phase 1 establishes, then the key values matched.

Step 4 : If you don’t get the expected output from the above, check whether the PSK is configured both sides

Step 5 : : If you don’t get the expected output from the above, verify the ISAKMP negotiation

• Part of the Phase 1 purpose is to negotiate with the peer how they are going to authenticate the tunnel. ISAKMP policies define this.
• The controller predefines policies as shown in the output. These are used with different purposes as clued by their names.
• If the peer devices cannot agree on a policy, then the tunnel fails. Ensure both ends have matching policies

Step 6 : Debugging

• Enabling debug level for the security log crypto, authmgr, localdb and l2tp processes may help in identifying IPSec issues.
• These provide detailed visibility in their authentication processes.

The following debugging will help to identify IPSec issues.

• L2TP debugging:
  #logging level debugging security process l2tp
• IKE debugging:
  #logging level debugging security process crypto
• Authmgr debugging:
  #logging level debugging security process authmgr
• Localdb debugging:
  #logging level debugging security process localdb

IKE negotiation :

IKE authentication Failed :

IKE successful authentication and successful SA :

I believe this Trouble shooting guide will help all my friends, please share your feedback so that I can create some more TS guides on Aruba.

Please feel free to share your thoughts.

Please correct this article so it says ESP protocol 50, not UDP 50.