Juniper SRX VPN Troubleshooting

>show security ike security-associations 1.1.1.1 detail
>show security ike security-associations inactive
>show security ike active-peer
>show security ipsec security-associations vpn-name my_vpn
>show security ipsec security-associations vpn-name my_vpn traffic-selector t1
>show security ipsec inactive-tunnels
>show security ipsec statistics
>show interfaces st0.0 extensive

>show security flow session interface st0.0

>request security ike debug-enable local 173.167.224.13 remote 99.182.0.14 level 15

level 15 is a hidden command

>show security ike debug-status
>show log kmd

The below can narrow the output

>sh>show log kmd | match "ike|initiator|responder" 
>request security ike debug-disable

To troubleshoot inactive VPN 

>sh>show log kmd# set system syslog file kmd-logs daemon info
# set system syslog file kmd-logs match KMD
# commit

> show log kmd-logs | match peer_IP

To show number of packets through the tunnel use the command below. Narrow done by using “index”. As in the example below, a lot of packets are encrypted, but nothing back from neighbor:

srxA-2> show security ipsec security-associations          
  Total active tunnels: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway   
  <131073 ESP:3des/sha1 e9618669 664/  unlim   -   root 500   192.168.11.1    
  >131073 ESP:3des/sha1 eda114c0 664/  unlim   -   root 500   192.168.11.1    

srxA-2> show security ipsec statistics index 131073  
ESP Statistics:
  Encrypted bytes:            15368
  Decrypted bytes:                0
  Encrypted packets:            113
  Decrypted packets:              0
AH Statistics:
  Input bytes:                    0
  Output bytes:                   0
  Input packets:                  0
  Output packets:                 0
Errors:
  AH authentication failures: 0, Replay errors: 0
  ESP authentication failures: 0, ESP decryption failures: 0
  Bad headers: 0, Bad trailers: 0

Reading the Logs:

Phase 1:
The following is an example from Kmd Log.   The most recent message is listed at the bottom. The above steps may display IKE Phase 2 and/or Phase 1 messages as below.   

Successful VPN connection:

Phase-1 [responder] done for local=ipv4(udp:500,[0..3]=1.1.1.2) remote=ipv4(udp:500,[0..3]=2.2.2.2)

Phase-2 [responder] done for p1_local=ipv4(udp:500,[0..3]=1.1.1.2) p1_remote=ipv4(udp:500,[0..3]=2.2.2.2) p2_local=ipv4_subnet(any:0,[0..7]=10.10.10.0/24) p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24)

Failing due to phase 1 proposal mismatch:

Phase-1 [responder] failed with error(No proposal chosen) for local=unknown(any:0,[0..0]=) remote=ipv4(any:0,[0..3]=2.2.2.2)1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { 011359c9 ddef501d – 2216ed2a bfc50f5f [-1] / 0x00000000 } IP; Error = No proposal chosen (14)

Resolution: Confirm that all phase 1 proposal elements match exactly on both peers. Confirm external interface is correct.

Failing due to unrecognized peer:

Unable to find phase-1 policy as remote peer:2.2.2.2 is not recognized.KMD_PM_P1_POLICY_LOOKUP_FAILURE: Policy lookup for Phase-1 [responder] failed for p1_local=ipv4(any:0,[0..3]=1.1.1.2) p1_remote=ipv4(any:0,[0..3]=2.2.2.2)1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { 18983055 dbe1d0af – a4d6d829 f9ed3bba [-1] / 0x00000000 } IP; Error = No proposal chosen (14)

Resolution: Confirm peer ID type is correct (IP address, hostname, or user@hostname). Once peer ID type is confirmed then also confirm the ID itself is correct.

Failing due to pre-shared key mismatch:

1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { e9211eb9 b59d543c – 766a826d bd1d5ca1 [-1] / 0x00000000 } IP; Invalid next payload type = 17 Phase-1 [responder] failed with error(Invalid payload type) for local=unknown(any:0,[0..0]=) remote=ipv4(any:0,[0..3]=2.2.2.2)

Resolution: Re-enter pre-shared key on both peers to ensure that they match.

Failing due to phase 2 proposal mismatch:

Phase-1 [responder] done for local=ipv4(udp:500,[0..3]=1.1.1.2) remote=ipv4(udp:500,[0..3]=2.2.2.2)1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { cd9dff36 4888d398 – 6b0d3933 f0bc8e26 [0] / 0x1747248b } QM; Error = No proposal chosen (14)

Resolution: Confirm all phase 2 elements match exactly on both peers. Confirm tunnel policy exists.

Failing due to phase 2 proxy ID mismatch:

Phase-1 [responder] done for local=ipv4(udp:500,[0..3]=1.1.1.2) remote=ipv4(udp:500,[0..3]=2.2.2.2) Failed to match the peer proxy ids p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24) p2_local=ipv4_subnet(any:0,[0..7]=10.10.20.0/24) for the remote peer:ipv4(udp:500,[0..3]=2.2.2.2)KMD_PM_P2_POLICY_LOOKUP_FAILURE: Policy lookup for Phase-2 [responder] failed for p1_local=ipv4(udp:500,[0..3]=1.1.1.2) p1_remote=ipv4(udp:500,[0..3]=2.2.2.2) p2_local=ipv4_subnet(any:0,[0..7]=10.10.20.0/24) p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24)1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { 41f638eb cc22bbfe – 43fd0e85 b4f619d5 [0] / 0xc77fafcf } QM; Error = No proposal chosen (14).

Resolution: Confirm that tunnel policy has correct address book entries as well as application or service. Check to see if manual proxy-id configured on gateway.

If there are no messages; make sure the correct IP address was used.   It is also possible that the Kmd Log filled up with other messages, so try to ping across the tunnel in order to attempt to bring the VPN up again.  If there are still no messages, refer to KB10100- How to Troubleshoot a Site-to-Site VPN Tunnel that wont come up.

Phase 2:
Phase-2 [responder] done for p1_local=ipv4(udp:500,[0..3]=1.1.1.2) p1_remote=ipv4(udp:500,[0..3]=2.2.2.2) p2_local=ipv4_subnet(any:0,[0..7]=10.10.10.0/24) p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24)

Where 2.2.2.2 is the IP address of the remote firewall in question.  

The most common Phase 2 errors are:

Message: 1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { cd9dff36 4888d398 – 6b0d3933 f0bc8e26 [0] / 0x1747248b } QM; Error = No proposal chosen (14)

Meaning:  The JUNOS device did not accept any of the IKE Phase 2 proposals that the specified IKE peer sent.

Action: Check the local VPN configuration. Either change the local configuration to accept at least one of the remote peer’s Phase 2 proposals, or contact the remote peer’s admin and arrange for the IKE configurations at both ends of the tunnel to use at least one mutually acceptable Phase 2 proposal. 

For assistance, see KB10123 – Received Message: Error = No proposal chosen (14).            

Message: Failed to match the peer proxy ids p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24) p2_local=ipv4_subnet(any:0,[0..7]=10.10.20.0/24) for the remote peer:ipv4(udp:500,[0..3]=2.2.2.2)

Meaning:  No policy found matching the specified attributes

Action: The proxy-id must be an exact “reverse” match.  For example, the address book entries must have the same number of netmask bits, the list of services must match as well as the port numbers.  If any of these fields don’t match, the Phase 2 will fail.  Check the address and/or service book entries. 

Leave a Reply

Your email address will not be published. Required fields are marked *