JNCIE-SEC IPSEC & NAT

Below is the list of topics for IPSEC and NAT that you may see in JNCIE-SEC exam according to exam page. I will not only talk about exam topics but also in general about protocols and my troubleshooting tests. I would like to start JNCIE-SEC with IPSEC as I have lack of knowledge in this topic. I also would like to improve this JNCIE-SEC journal with the help of readers. You are encouraged to send your own case studies. Just for your information, the content I am going to create about this exam is all about my interpretation of the topics published by Juniper. I may not adhere %100 to exam topics and from time to time I can write about something that isn’t relevant to the exam. Without further ado, let’s begin the journey;

IPsec VPNs

NAT

  • Implementation of NAT
  • Source NAT
  • Destination NAT
  • Static NAT
  • Implementation of NAT with IPSec
  • Overlapping IPs between sites


Implementation of IPsec VPNs

IPSEC has two phases IKE Phase 1 and Phase 2. IKE Phase 1 has also two modes.

  • Main Mode
  • Aggressive Mode

Main Mode
Here is a simple site to site route based VPN topology.

ipsec_peers_route_based

Below is a wireshark capture of these two peers’ IPSEC negotiation.

ipsec_main_mode_setup

Click to download the pcap file

Main mode has three two-way exchanges. In the first exchange initiator may propose several proposals i.e their encryption algorithms, hashes, authentication method, lifetime etc. but responder must reply with one. Practically speaking what you see in this exchange is what you configure in SRX’s IKE proposal for the specific connection;

[edit security]
root@jgw23# show ike proposal ike-prop-1 
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
lifetime-seconds 1800;

In the second exchange peers use Diffie-Hellman, it is used to generate keying material to exchange shared secrets.

Third exchange is where encrypted communication starts. Peers verify their identities, PSKs exchanged etc.

Once this 6 messages are exchanged IKE Phase 2 starts which has only one mode: Quick Mode
In this mode, communication is already encrypted provided by IKE phase 1. Here IPSEC SAs are established and it is also used to renegotiate when IPSEC lifetime expires.

Practically this is what we get once IKE and IPSEC SAs are established

root@jgw23> show security ike sa detail 
IKE peer 212.45.64.2, Index 5957443, Gateway Name: gw-hub
  Role: Responder, State: UP
  Initiator cookie: 4ede589f52cef9c9, Responder cookie: 8c9d70cb3a4ce3f2
  Exchange type: Main, Authentication method: Pre-shared-keys
  Local: 192.168.179.2:500, Remote: 212.45.64.2:500
  Lifetime: Expires in 560 seconds
  Peer ike-id: 212.45.64.2
  Xauth assigned IP: 0.0.0.0
  Algorithms:
   Authentication        : hmac-sha1-96 
   Encryption            : 3des-cbc
   Pseudo random function: hmac-sha1
   Diffie-Hellman group  : DH-group-2
  Traffic statistics:
   Input  bytes  :                 6460
   Output bytes  :                 6400
   Input  packets:                   73
   Output packets:                   74
  Flags: IKE SA is created 
  IPSec security associations: 0 created, 0 deleted
  Phase 2 negotiations in progress: 0

    Negotiation type: Quick mode, Role: Responder, Message ID: 0
    Local: 192.168.179.2:500, Remote: 212.45.64.2:500
    Local identity: 192.168.179.2
    Remote identity: 212.45.64.2
    Flags: IKE SA is created


root@jgw23> show security ipsec sa detail 
  ID: 131073 Virtual-system: root, VPN Name: vpn-hub
  Local Gateway: 192.168.179.2, Remote Gateway: 212.45.64.2
  Local Identity: ipv4(any:0,[0..3]=11.11.11.2)
  Remote Identity: ipv4(any:0,[0..3]=11.11.11.1)
  Version: IKEv1
    DF-bit: clear
    Bind-interface: st0.0

  Port: 500, Nego#: 2, Fail#: 0, Def-Del#: 0 Flag: 600a29 
  Tunnel Down Reason: Delete payload received
    Direction: inbound, SPI: 6be505e0, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 1718 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 1125 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: outbound, SPI: a352cf0f, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 1718 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 1125 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
    Anti-replay service: counter-based enabled, Replay window size: 64

Note: Initiator cookie doesn’t match the packet capture as it was taken during
another IPSEC negotiation.

Let’s send a 1000 byte ICMP packet from J23 and see how it looks on the wire;

ICMP ECHO REQUEST
ipsec_esp_echo

If you look at the packet capture our IP packet (echo request) is encapsulated and SPI is a352cf0f
which is what we see in the command output for outbound direction.

ICMP ECHO REPLY
ipsec_esp_echo_reply

You can also see the SPI 6be505e0 in the inbound direction of the packet capture.

IPSEC SA management has different behavior between different releases. You may check KB26692 to see the difference.

When you have an established IPSEC SA, you have also two sessions installed for this;

root@jgw23> show security flow session protocol esp 
Session ID: 1, Policy name: N/A, Timeout: N/A, Valid
  In: 212.45.64.2/61727 --> 192.168.179.2/35206;esp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0

Session ID: 2, Policy name: N/A, Timeout: N/A, Valid
  In: 212.45.64.2/0 --> 192.168.179.2/0;esp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0
Total sessions: 2

These are inbound sessions only but I don’t recall the reason for two of them instead of one.

I would like to end this post here though it isn’t really a VPN implementation post, I just wanted to make an introduction for future posts in which I will do more practical stuff.

About: rtoodtoo

Genco has worked for more than 10 years as a Network/Support Engineer. He is also interested in Python, Linux, Security and SD-WAN, currently lives in the Netherlands and works as a Network Support Engineer at Tesla Inc. // JNCIE-SEC #223 / RHCE / PCNSE


You have a feedback?

This site uses Akismet to reduce spam. Learn how your comment data is processed.