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
- Implementation of IPsec VPNs
- Multipoint tunnels
- Policy and route-based VPNs
- Traceoptions
- Dual and backup tunnels
- On-demand tunnels
- DRP over a tunnel
- Dynamic VPNs
- Certificate-based VPNs
- PKI
- Interoperability with 3rd party devices
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.
Below is a wireshark capture of these two peers’ IPSEC negotiation.
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
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
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.
