Description

SRX negotiates NAT-T by default. A user can manually disable NAT-T. However, even if there is no NAT device between SRX and client, NAT-T must be enabled for Dynamic VPN negotiations.

Symptoms

The following command is used to disable NAT-T:

root@SRX240_3# set security ike gateway dyn-vpn-local-gw no-nat-traversal

The VPN cannot be established:

root@SRX240_3# run show security ipsec security-associations
  Total active tunnels: 0

Errors are seen  in the ike traceoption: 

[Aug  9 02:17:19]10.75.252.17:500 (Responder) <-> 10.75.252.123:60677 { 16cd1b75 b0c3e4f7 - f87964a6 507906f6 [-1] / 0x00000000 } Aggr; No payloads in packet
[Aug  9 02:17:19]10.75.252.17:500 (Responder) <-> 10.75.252.123:60677 { 16cd1b75 b0c3e4f7 - f87964a6 507906f6 [-1] / 0x00000000 } Aggr; Error = Payload malformed (16)
[Aug  9 01:59:00]IKE negotiation fail for local:10.75.252.17, remote:10.141.25.37 IKEv1 with status: Invalid syntax

Solution

The packet capture of IKE negotiations

The NAT-T is open by default on PC as shown below :


 

Comparing with SRX, since we closed NAT-T, the payload does not have NAT-T as shown below:

 
 

According to RFC3947 , NAT-T must be opened for both sides:

"The NAT-Traversal capability of the remote host is determined by an  exchange of vendor ID payloads.  In the first two messages of Phase- 1, the vendor id payload for this specification MUST be sent if  supported (and it MUST be received by both sides ) for the NAT- Traversal probe to continue."
 

While there is no NAT device between client and SRX, NAT-T must be enabled on SRX because the VPN client running on the PC is generally designed to negotiate NAT-T by default.

If the NAT-T capabilities are NOT exchanged, the VPN negotiation will fail with the error 'Payload malformed'.

Do not use the command, 'no-nat-traversal' when using dynamic VPN.