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.

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.