JNCIP-SEC [ 5 – Advanced IPSEC ] Part 1
Yes again I would like to write something about ipsec vpn. It won’t cover everything about the jncip-sec exam but I would like to compile something that I can also use in the future as a reference. As I have said in my previous posts, any constructive comment,feedback is welcomed. Lets get started.
1) Point to Point IPSEC VPN configuration and troubleshooting in SRX
The first topic I have chosen is point to point IPSEC VPN. Below is the topology I have used.
IP Allocation:
SRX1
ge-0/0/0.0 : 10.1.1.2/24
ge-0/0.1.0 : 172.16.100.1/24
GW: 10.1.1.1
SRX2
ge-0/0/0.0 : 10.2.2.2/24
ge-0/0/1.0: 172.16.200.1/24
GW: 10.2.2.1
Server1: 172.16.100.2/24
Server2: 172.16. 200.2/24
First Configure SRX1 as follows:
[edit security]
root@srx1# show ike
proposal prop-basic {
authentication-method pre-shared-keys;
dh-group group2;
encryption-algorithm 3des-cbc;
lifetime-seconds 3600;
}
policy pol-basic {
mode main;
proposals prop-basic;
pre-shared-key ascii-text "$9$m5z6p0IreW9AeWLxwsP5QF9AuO1hyl";
}
gateway srx2 {
ike-policy pol-basic;
address 10.2.2.2;
dead-peer-detection {
interval 10;
threshold 5;
}
external-interface ge-0/0/0.0;
}
[edit security]
root@srx1# show ipsec
proposal prop-basic {
protocol esp;
authentication-algorithm hmac-md5-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 3600;
}
policy pol-basic {
proposals prop-basic;
}
vpn p2p-srx2 {
bind-interface st0.0;
ike {
gateway srx2;
ipsec-policy pol-basic;
}
establish-tunnels immediately;
}
[edit]
root@srx1# show interfaces st0.0
family inet {
mtu 1490;
address 10.11.11.1/30;
}
Tunnel interface address may even be an arbitrary address. We also decrease the MTU of st0 interface because of the extra header stemming from tunnel.
root@srx1# show routing-options
static {
route 172.16.200.0/24 next-hop st0.0;
route 10.2.2.0/24 next-hop 10.1.1.1;
}
I am not going to fill up this post with configurations. So I attached the entire configuration of srx2 configure so far here. You can also take a look at the security policies.
Now after I configured these two SRX devices for point-to-point ipsec vpn configuration I got two issues because of those “show security ike security-associations” returned no output.
- I noticed that I forgot to add ike protocol on srx2’s outside interface ge-0/0/0.0
- After ike protocol activation, I stil got no output upon show command. Then I enabled traceoptions under ike as follows
[edit]
root@srx1# show security ike
traceoptions {
file ike-p2p.log;
flag all;
}
This generate the file /var/log/ike-p2p.log content of which was below;
Sep 13 04:28:35 Deleting existing ipsec trace cfg with key: 1 Sep 13 04:28:35 iked_ipsec_trace_flag_update: Successfully added ipsec trace con fig with key Sep 13 04:28:35 kmd_sa_cfg_free: Tunnel node for tunnel 131073 (SA: p2p-srx2) no t found
Actually this didn’t ring any bell firstly but then I noticed that I forgot to assign st0.0 interface to a zone. (I do it always:) After I assigned st0.0 tunnel interfaces on both nodes to the zone named vpn I got the following output.
root@srx1> show security ike security-associations Index Remote Address State Initiator cookie Responder cookie Mode 5879392 10.2.2.2 UP ece62d77995b5a69 7eac1054a78a210b Main root@srx1> show security ipsec security-associations Total active tunnels: 1 ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys <131073 10.2.2.2 500 ESP:3des/md5 d721619c 2113/ unlim - root >131073 10.2.2.2 500 ESP:3des/md5 211ddf92 2113/ unlim - root
We brought the tunnel up!
TIP: In order traffic to flow make sure security policies are created from zone vpn to trust and from trust to vpn separately in each device. Once the security polices are created, lets troubleshoot the traffic.
To get detail output regarding security associations on both IKE and IPSEC, we can issue following commands;
root@srx1> show security ike security-associations detail
IKE peer 10.2.2.2, Index 5635157,
Role: Responder, State: UP
Initiator cookie: 7fa1739b67687fcb, Responder cookie: 32cff26407f75246
Exchange type: Main, Authentication method: Pre-shared-keys
Local: 10.1.1.2:500, Remote: 10.2.2.2:500
Lifetime: Expires in 1671 seconds
Peer ike-id: 10.2.2.2
Xauth assigned IP: 0.0.0.0
Algorithms:
Authentication : sha1
Encryption : 3des-cbc
Pseudo random function: hmac-sha1
Traffic statistics:
Input bytes : 13072
Output bytes : 13004
Input packets: 150
Output packets: 149
Flags: Caller notification sent
IPSec security associations: 1 created, 0 deleted
Phase 2 negotiations in progress: 0
root@srx1> show security ipsec security-associations detail
Virtual-system: root
Local Gateway: 10.1.1.2, Remote Gateway: 10.2.2.2
Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
DF-bit: clear
Direction: inbound, SPI: d4bcf0fc, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 1662 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 1085 seconds
Mode: tunnel, Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-md5-96, Encryption: 3des-cbc
Anti-replay service: counter-based enabled, Replay window size: 64
Direction: outbound, SPI: 3fb9b515, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 1662 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 1085 seconds
Mode: tunnel, Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-md5-96, Encryption: 3des-cbc
Anti-replay service: counter-based enabled, Replay window size: 64
I have generated a continuos ping from server1 device (172.16.100.2) to address 172.16.200.1 which is ge-0/0/1.0 of srx2 device. Lets check session table of this traffic
root@srx1> show security flow session destination-prefix 172.16.200.0/24 Session ID: 1880, Policy name: vpn-permit/4, Timeout: 2, Valid In: 172.16.100.2/32516 --> 172.16.200.1/512;icmp, If: ge-0/0/1.0, Pkts: 1, Bytes: 60 Out: 172.16.200.1/512 --> 172.16.100.2/32516;icmp, If: st0.0, Pkts: 1, Bytes: 60 Session ID: 1881, Policy name: vpn-permit/4, Timeout: 2, Valid In: 172.16.100.2/32772 --> 172.16.200.1/512;icmp, If: ge-0/0/1.0, Pkts: 1, Bytes: 60 Out: 172.16.200.1/512 --> 172.16.100.2/32772;icmp, If: st0.0, Pkts: 1, Bytes: 60
As it can be seen policy “vpn-permit” allows packets coming from ge-0/0/1.0 destined to st0.0
So far all the configuration was based on route-based vpn. I must also add policy based configuration. After some minor changes I transformed the route-based configuration to policy based. Here it is;
[edit]
root@srx1# show security
proposal prop-basic {
authentication-method pre-shared-keys;
dh-group group2;
encryption-algorithm 3des-cbc;
lifetime-seconds 3600;
}
policy pol-basic {
mode main;
proposals prop-basic;
pre-shared-key ascii-text "$9$m5z6p0IreW9sedAeWLxwsP5QF9AuO1hyl";
}
gateway srx2 {
ike-policy pol-basic;
address 10.2.2.2;
dead-peer-detection {
interval 10;
threshold 5;
}
external-interface ge-0/0/0.0;
}
}
ipsec {
traceoptions {
flag all;
}
proposal prop-basic {
protocol esp;
authentication-algorithm hmac-md5-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 3600;
}
policy pol-basic {
proposals prop-basic;
}
vpn p2p-srx2 {
ike {
gateway srx2;
ipsec-policy pol-basic;
}
}
}
zones {
security-zone untrust {
address-book {
address clients_200 172.16.200.0/24;
}
interfaces {
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
ping;
traceroute;
ike;
ssh;
}
}
}
}
}
security-zone trust {
address-book {
address clients_100 172.16.100.0/24;
}
interfaces {
ge-0/0/1.0 {
host-inbound-traffic {
system-services {
all;
}
}
}
}
}
}
policies {
from-zone trust to-zone untrust {
policy vpn-permit-out {
match {
source-address clients_100;
destination-address clients_200;
application any;
}
then {
permit {
tunnel {
ipsec-vpn p2p-srx2;
pair-policy vpn-permit-in;
}
}
}
}
}
from-zone untrust to-zone trust {
policy vpn-permit-in {
match {
source-address clients_200;
destination-address clients_100;
application any;
}
then {
permit {
tunnel {
ipsec-vpn p2p-srx2;
pair-policy vpn-permit-out;
}
}
}
}
}
}
To transform route-based to policy based, I did the followings:
- static routes pointing to st0.0 removed
- bind-interface ipsec/vpn configuration removed
- policies for inbound and outbound initiated connections are added with permit tunnel action.
All jncip-sec posts in this blog are the result of my own studies with my SRX 210 hardware and shouldn’t be considered as an exam training replacement.
