Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[SRX] How to verify if the phase 1 proposals are being received from the peer gateway



Article ID: KB26292 KB Last Updated: 18 Jun 2020Version: 2.0

This article provides information on how to verify if the phase 1 proposals are being received from the peer gateway.

  • When you do not have access to the peer gateway and want to verify the phase 1 proposals, there are two ways to do this; via the IKE traceoptions log file or by taking a packet capture (or just monitor the external interface traffic).

  • This article provides information on how to check the encryption-algorithm, authentication-algorithm, and dh-group. You can also view the lifetime-seconds and authentication method.


Two SRX 100 firewalls are directly connected via the fe-0/0/0 interface. For the sake of simplicity, the IP address on one firewall (100A) is and on the other one (100B), it is An attempt is made to establish a VPN between these two devices.

Proposal on 100A:

proposal 100A {
    authentication-method pre-shared-keys;
    dh-group group2;
    authentication-algorithm sha-256;
    encryption-algorithm aes-256-cbc;

Proposal on 100B:

proposal 100B {
    authentication-method pre-shared-keys;
    dh-group group14;
    authentication-algorithm sha-256;
    encryption-algorithm aes-256-cbc;

The proposals are different on both of the firewalls to ensure that the VPN does not come up and you get a chance to see the packets that contain the transforms. Also, the establish-tunnels are immediately removed from 100A, so that only 100B initiates the VPN and sends its proposal first to 100A.

When there is only 1 VPN, you can check the proposal just by running the monitor traffic interface command:

root@100A# run monitor traffic interface fe-0/0/0.0 layer2-headers no-resolve matching udp size 1500    
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on fe-0/0/0.0, capture size 1500 bytes

06:57:13.010577  In PFE proto 2 (ipv4): > isakmp: phase 1 I ident:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1 spi=8d9e93bdfd21a035
            (t: #0 id=ike (type=enc value=0007)(type=keylen value=0100)(type=group desc value=000e)
(type=hash value=0004)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)(type=auth value=preshared))))

The first pair in the transform illustrates the encryption algorithm, in which the first is the encryption algorithm and the second is the key length. The possible values are as follows:

(type=enc value=0007) for aes
(type=enc value=3des) for 3des
(type=enc value=1des) for des
(type=keylen value=00c0) for 192
(type=keylen value=0080) for 128
(type=keylen value=0100) for 256

Which provides the following algorithms:

(type=enc value=0007)(type=keylen value=00c0) for aes-192
(type=enc value=0007)(type=keylen value=0080) for aes-128
(type=enc value=0007)(type=keylen value=0100) for aes-256
(type=enc value=3des) for 3des
(type=enc value=1des) for des-cbc

The third term illustrates the dh-group, for which the possible values and their respective descriptions are as follows:

(type=group desc value=modp768) for group1
(type=group desc value=modp1024) for group2
(type=group desc value=0005) for group5
(type=group desc value=000e) for group14

The fourth term specifies the authentication algorithm, for which the possible values are as follows:

(type=hash value=md5) for md5
(type=hash value=0004) for sha-256
(type=hash value=sha1) for sha1

The monitor command to view proposals is not very useful, if multiple IKE negotiation are taking place. It is easier to obtain a packet capture by performing the following procedure:

  1. Configure a firewall filter on 100A to sample UDP traffic from
    root@100A# show firewall 
    filter ike {
        term t1 {
            from {
                destination-address {
                protocol udp;
            then {
        term t2 {
            then accept;
  2. Apply this firewall filter on the fe-0/0/0 interface:

    root@100A# show interfaces fe-0/0/0 
    unit 0 {
        family inet {
            filter {
                input ike;
  3. Configure the forwarding-options packet capture:

    root@100A# show forwarding-options 
    packet-capture {
        file filename ike;
        maximum-capture-size 1500;
  4. Now read the packet capture file in the shell via tcpdump:

    root@100A% tcpdump -r /var/tmp/ike.fe-0.0.0 | grep type
    Reverse lookup for failed (check DNS reachability).
    Other reverse lookup failures will not be reported.
    Use <no-resolve> to avoid reverse lookups on IP addresses.
                (t: #0 id=ike (type=enc value=0007)(type=keylen value=0100)
    (type=group desc value=000e)(type=hash value=0004)(type=lifetype value=sec)
    (type=lifeduration len=4 value=00007080)(type=auth value=preshared))))
Modification History:

2020-06-18: Article reviewed for accuracy; no changes required.

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search