JNCIE-SEC Multipoint tunnels/Policy and route based VPNs

After the introduction to IPSEC a little bit, I am following with the second task and third task in the list which are Multipoint tunnels and policy/route based VPNs. Some of these individual tasks have overlapping case studies because of this I may not write a single post for each task.

IPsec VPNs

NAT

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

Our case study is that we have a company headquarter of which is in Amsterdam and has two offices in London and Paris. We will connect these two offices to Amsterdam HQ via an IPSEC tunnel. London office is route based and Paris office will connect via policy based VPN. Protected networks are assigned to ge-0/0/1.0 interface of each SRX device.

ipsec_multipoint_route_policy_based_vpn

Below is the IPSEC config of J41 IPSEC HUB. Tunnel interface is marked as multipoint and assigned to the security zone vpn and IKE is allowed on external-interface.

[edit]
root@J41-Amsterdam# show security ike 
proposal ike-prop-1 {
    authentication-method pre-shared-keys;
    dh-group group2;
    authentication-algorithm sha1;
    encryption-algorithm 3des-cbc;
    lifetime-seconds 14400;
}
policy ike-pol-1 {
    mode main;
    proposals ike-prop-1;
    pre-shared-key ascii-text "$9$E8DhrvW87dVYvMaZji.m"; ## SECRET-DATA
}
gateway gw-23 {
    ike-policy ike-pol-1;
    address 192.168.179.2;
    external-interface ge-0/0/0.64;
}

[edit]
root@J41-Amsterdam# show security ipsec 
proposal ipsec-prop-1 {
    protocol esp;
    authentication-algorithm hmac-sha1-96;
    encryption-algorithm 3des-cbc;
    lifetime-seconds 3600;
}
policy ipsec-pol-1 {
    proposals ipsec-prop-1;
}
vpn vpn-23 {
    bind-interface st0.0;
    ike {
        gateway gw-23;
        ipsec-policy ipsec-pol-1;
    }
    establish-tunnels immediately;
}

[edit]
root@J41-Amsterdam# show interfaces st0.0 
multipoint;
family inet {
    address 11.11.11.1/24;
}

[edit]
root@J41-Amsterdam# show security zones security-zone vpn 
interfaces {
    st0.0;
}

[edit security zones]
root@J41-Amsterdam# show security-zone external-a 
address-book {
    address net_10.225.225 10.225.225.0/24;
}
host-inbound-traffic {
    system-services {
        ping;
        ssh;
        ike;
    }
    protocols {
        bgp;
    }
}
interfaces {
    ge-0/0/0.64;
    ge-0/0/0.65;
}

J23 spoke configuration. It is very similar to HUB but st0.0 interface is
without multipoint option.

[edit]
root@J23-London# show security ike 
proposal ike-prop-1 {
    authentication-method pre-shared-keys;
    dh-group group2;
    authentication-algorithm sha1;
    encryption-algorithm 3des-cbc;
    lifetime-seconds 3600;
}
policy ike-pol-1 {
    mode main;
    proposals ike-prop-1;
    pre-shared-key ascii-text "$9$aSJDk.mTF39kquOREyr"; ## SECRET-DATA
}
gateway gw-hub {
    ike-policy ike-pol-1;
    address 212.45.64.2;
    external-interface ge-0/0/0.0;
}

[edit]
root@J23-London# show security ipsec 
proposal ipsec-prop-1 {
    protocol esp;
    authentication-algorithm hmac-sha1-96;
    encryption-algorithm 3des-cbc;
    lifetime-seconds 3600;
}
policy ipsec-pol-1 {
    proposals ipsec-prop-1;
}
vpn vpn-hub {
    bind-interface st0.0;
    ike {
        gateway gw-hub;
        ipsec-policy ipsec-pol-1;
    }
}

[edit]
root@J23-London# show interfaces st0.0 
family inet {
    address 11.11.11.2/24;
}

root@J23-London# show security zones security-zone vpn 
interfaces {
    st0.0;
}

root@J23-London# show security zones security-zone external 
interfaces {
    ge-0/0/0.0 {
        host-inbound-traffic {
            system-services {
                ssh;
                ping;
                ike;
            }
        }
    }
}

Check if IKE Phase1 and Phase2 have been established:

root@J23-London> show security ike sa detail 
IKE peer 212.45.64.2, Index 6388075, Gateway Name: gw-hub
  Role: Responder, State: UP
  Initiator cookie: 652caa5b5e60b9c9, Responder cookie: 8dabc885c1dbf70c
  Exchange type: Main, Authentication method: Pre-shared-keys
  Local: 192.168.179.2:500, Remote: 212.45.64.2:500
  Lifetime: Expires in 12830 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  :                  836
   Output bytes  :                  632
   Input  packets:                    5
   Output packets:                    4
  Flags: IKE SA is created 
  IPSec security associations: 1 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@J23-London> show security ipsec sa         
  Total active tunnels: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway   
  <131073 ESP:3des/sha1 87f9148b 2025/ unlim   -   root 500   212.45.64.2     
  >131073 ESP:3des/sha1 6d064790 2025/ unlim   -   root 500   212.45.64.2     

I have shown IKE output in detail to show you that Phase 1 lifetime mismatch between J23(3600secs) and J41(14400secs) According to RFC2409 lifetime isn’t among MUST be negotiated parameters and what I have seen is responder accepts what the initiator sends. In our case J23 accepts the 14400secs offer.

This setup was an ideal case which means we set it up and it worked but you may see numerous cases that IKE Phase 1 isn’t coming up and you don’t always see the reason in traceoptions. Here is the list to check if your IKE phase isn’t coming up from my experience;

Make sure:

  • IKE gateways have IP connectivity
  • UDP port 500 isn’t blocked anywhere in the path
  • There is no additional IP address configured on IKE external interfaces other than the IKE gateway IP
    You may initiate packets from wrong source address. You can work around this but better not to have it.
  • There is no firewall filter blocking UDP port 500 on lo0.0 interface.
  • Parameters you set match at both side

Soft Lifetime / Hard Lifetime
An IPSEC SA has both soft and hard life time. Below is an example output from another day (SPIs are different);

root@J23-London> show security ipsec sa        
  Total active tunnels: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway  
  <131073 ESP:3des/sha1 e3b2d899 631/  unlim   -   root 500   212.45.64.2    
  >131073 ESP:3des/sha1 aaa8fcb0 631/  unlim   -   root 500   212.45.64.2    
  <131073 ESP:3des/sha1 63c0bd98 3597/ unlim   -   root 500   212.45.64.2    
  >131073 ESP:3des/sha1 f7296421 3597/ unlim   -   root 500   212.45.64.2    

This says soft life time expired for the tunnel 131073 and after a new quick mode re-key, new SAs have been established (SPI:63c0bd98 and f7296421). But what does this mean in practical terms;

ipsec_rekey_quick_mode

I initiated a ping just before the soft lifetime expires. As you can see in the wireshark capture just after the re-key peers stop using old SPIs and switch to the new tunnel SPIs and the old SPIs disappear from the list before lifetime counts down to zero.

Route Based VPN

Now it is time to protect traffic between 55.55.55.0/24 network and 212.45.63.0/24 network

Routes in two ways have been added and installed. One point we must pay attention to is that multipoint side route’s next-hop isn’t st0.0 interface. The reason is that there are multiple gateways behind this interface and next-hop to an interface can’t identify the right gateway. Because of which we must set the route to next-hop which we see in next-hop-tunnels output.

root@J23-London> show route 212.45.63.0/24 terse 

inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop         AS path
* 212.45.63.0/24     S   5                       >st0.0 

root@J41-Amsterdam> show route 55.55.55.0/24 terse 

inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop         AS path
* 55.55.55.0/24      S   5                       >11.11.11.2

root@J41-Amsterdam> show security ipsec next-hop-tunnels 
Next-hop gateway  interface   IPSec VPN name                    Flag     IKE-ID                            XAUTH username
11.11.11.2        st0.0       vpn-23                            Auto     192.168.179.2     

The following policies allow VPN traffic in both directions in both nodes.


[edit]
root@J23-London# show security policies 
from-zone internal to-zone vpn {
    policy internal-to-vpn {
        match {
            source-address net_55;
            destination-address vpn_net_212.45.63;
            application any;
        }
        then {
            permit;
        }
    }
}
from-zone vpn to-zone internal {
    policy vpn-to-internal {
        match {
            source-address vpn_net_212.45.63;
            destination-address net_55;
            application any;
        }
        then {
            permit;
        }
    }
}

[edit]
root@J41-Amsterdam# show security policies 
from-zone vpn to-zone internal {
    policy internal-to-vpn {
        match {
            source-address vpn_55.55.55.0;
            destination-address net_212.45.63.0;
            application any;
        }
        then {
            permit;
        }
    }
}
from-zone internal to-zone vpn {
    policy internal-to-vpn {
        match {
            source-address net_212.45.63.0;
            destination-address vpn_55.55.55.0;
            application any;
        }
        then {
            permit;
        }
    }
}



root@J23-London> ping 212.45.63.1 source 55.55.55.1 count 4 size 1300    
PING 212.45.63.1 (212.45.63.1): 1300 data bytes
1308 bytes from 212.45.63.1: icmp_seq=0 ttl=64 time=14.046 ms
1308 bytes from 212.45.63.1: icmp_seq=1 ttl=64 time=14.335 ms
1308 bytes from 212.45.63.1: icmp_seq=2 ttl=64 time=14.237 ms
1308 bytes from 212.45.63.1: icmp_seq=3 ttl=64 time=12.359 ms

--- 212.45.63.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 12.359/13.744/14.335/0.806 ms

Now we have a working Route Based VPN between two SRX peers. Time for Policy Based VPN!

Policy Based VPN

J41 HUB config
In policy based config

  • we don’t bind vpn to any stX interface.
  • Bidirectional security policies define which traffic to forward to tunnel
  • Source and destination addresses define the proxy ids of the tunnel if more than one address specified in any direction proxy id turns to 0.0.0.0

A new gateway for J21 device is defined under [edit security ike]

gateway gw-21 {
    ike-policy ike-pol-1;
    address 192.168.178.2;
    external-interface ge-0/0/0.64;
}

and a new VPN under [edit security ipsec]

vpn vpn-21 {
    ike {
        gateway gw-21;
        ipsec-policy ipsec-pol-1;
    }
    establish-tunnels immediately;
}

Bidirectional security policies. Pay attention to the pair-policy option, it references the policies in two directions.

/* Policy Based VPN J21 */
from-zone internal to-zone external-a {
    policy int-to-j21vpn {
        match {
            source-address net_212.45.63.0;
            destination-address net_10.225.225;
            application any;
        }
        then {
            permit {
                tunnel {
                    ipsec-vpn vpn-21;
                    pair-policy j21vpn-to-int;
                }
            }
        }
    }
}
/* Policy Based VPN J21 */
from-zone external-a to-zone internal {
    policy j21vpn-to-int {
        match {
            source-address net_10.225.225;
            destination-address net_212.45.63.0;
            application any;
        }
        then {
            permit {
                tunnel {
                    ipsec-vpn vpn-21;
                    pair-policy int-to-j21vpn;
                }
            }                           
        }
    }

J21 Spoke config
Spoke has also a similar config. (Security zone config is omitted, but is like the config in HUB)

[edit]
root@J21-Paris# show security ike 
proposal ike-prop-1 {
    authentication-method pre-shared-keys;
    dh-group group2;
    authentication-algorithm sha1;
    encryption-algorithm 3des-cbc;
    lifetime-seconds 14400;
}
policy ike-pol-1 {
    mode main;
    proposals ike-prop-1;
    pre-shared-key ascii-text "$9$bPwgJGUH.mTJZn/tpB1"; ## SECRET-DATA
}
gateway gwJ41-hub {
    ike-policy ike-pol-1;
    address 212.45.64.2;
    external-interface ge-0/0/0.0;
}

[edit]
root@J21-Paris# show security ipsec 
proposal ipsec-prop-1 {
    protocol esp;
    authentication-algorithm hmac-sha1-96;
    encryption-algorithm 3des-cbc;
    lifetime-seconds 3600;
}
policy ipsec-pol-1 {
    proposals ipsec-prop-1;
}
vpn vpn-j41 {
    ike {
        gateway gwJ41-hub;
        ipsec-policy ipsec-pol-1;
    }
    establish-tunnels immediately;
}

[edit]
root@J21-Paris# show security policies 
from-zone internal to-zone external {
    policy int-to-vpn {
        match {
            source-address net_10.225.225;
            destination-address net_212.45.63.0;
            application any;
        }
        then {
            permit {
                tunnel {
                    ipsec-vpn vpn-j41;
                    pair-policy vpn-to-int;
                }
            }
        }
    }
}
from-zone external to-zone internal {
    policy vpn-to-int {
        match {
            source-address net_212.45.63.0;
            destination-address net_10.225.225;
            application any;
        }
        then {
            permit {
                tunnel {
                    ipsec-vpn vpn-j41;
                    pair-policy int-to-vpn;
                }
            }
        }
    }
}

Verifying IPSEC tunnels

root@J41-Amsterdam> show security ike sa   
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address   
1647922 UP     854f8c7594d27d18  78a39c0332d05c66  Main           192.168.179.2   
1647921 UP     c7a7401b8d120a4d  50d097ded66402cd  Main           192.168.178.2   

root@J41-Amsterdam> show security ipsec sa 
  Total active tunnels: 2
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway   
  <2    ESP:3des/sha1   2b7d987d 1049/ unlim   -   root 500   192.168.178.2   
  >2    ESP:3des/sha1   c6fdcbd4 1049/ unlim   -   root 500   192.168.178.2   
  <131073 ESP:3des/sha1 2768afd5 1049/ unlim   -   root 500   192.168.179.2   
  >131073 ESP:3des/sha1 8ee31ef6 1049/ unlim   -   root 500   192.168.179.2 

Now we have two active tunnels, one is policy based (ID:2) and route based (ID:131073) If you display policy based tunnel by index, you will also see which policy is linked to this tunnel

Check the Policy-name field.

root@J41-Amsterdam> show security ipsec sa index 2  
  ID: 2 Virtual-system: root, VPN Name: vpn-21
  Local Gateway: 212.45.64.2, Remote Gateway: 192.168.178.2
  Local Identity: ipv4_subnet(any:0,[0..7]=212.45.63.0/24)
  Remote Identity: ipv4_subnet(any:0,[0..7]=10.225.225.0/24)
  Version: IKEv1
    DF-bit: clear
    Policy-name: int-to-j21vpn
  Port: 500, Nego#: 1, Fail#: 0, Def-Del#: 0 Flag: 600829 
  Tunnel Down Reason: SA not initiated
    Direction: inbound, SPI: 2b7d987d, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 800 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 178 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: c6fdcbd4, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 800 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 178 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

Verifying encrypted traffic

root@J21-Paris> ping 212.45.63.1 source 10.225.225.1 
PING 212.45.63.1 (212.45.63.1): 56 data bytes
^C
--- 212.45.63.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

Hmm it doesn’t work. I have enabled and seen that self-traffic-policy is hitting instead of int-to-vpn policy. Our ping command worked in route based VPN because self-traffic is forwarded to st0.0 interface by which encryption is done. However here we have to hit the right policy for encryption to happen. Actually I couldn’t find a way to do this without creating a routing instance. To make this ping successful, I had to make the following changes;

[edit]
root@J21-Paris# show security zones 
security-zone external {
    address-book {
        address net_212.45.63.0 212.45.63.0/24;
    }
    host-inbound-traffic {
        system-services {
            ike;
            ping;
            ssh;
        }
        protocols {
            ospf;
            bgp;
        }
    }
    interfaces {
        ge-0/0/0.0;
    }
}
security-zone internal {
    address-book {
        address net_10.225.225 10.225.225.0/24;
    }
    host-inbound-traffic {
        system-services {
            all;
        }
    }
    interfaces {
        lt-0/0/0.0;
    }
}
security-zone internal-vr {
    host-inbound-traffic {
        system-services {
            all;
        }
    }
    interfaces {
        ge-0/0/1.0;
        lt-0/0/0.1;
    }
}

[edit]
root@J21-Paris# show interfaces lt-0/0/0 
unit 0 {
    description root-vsys;
    encapsulation ethernet;
    peer-unit 1;
    family inet {
        address 1.1.1.1/30;
    }
}
unit 1 {
    description internal-vr;
    encapsulation ethernet;
    peer-unit 0;
    family inet {
        address 1.1.1.2/30;
    }
}

[edit]
root@J21-Paris# show routing-instances 
internal-vr {
    instance-type virtual-router;
    interface lt-0/0/0.1;
    interface ge-0/0/1.0;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop 1.1.1.1;
        }
    }
}

[edit]
root@J21-Paris# show routing-options 
static {
    route 0.0.0.0/0 next-hop 192.168.178.1;
}
router-id 192.168.178.2;
autonomous-system 9700;
instance-import int-vr-routes;

root@J21-Paris# show security policies from-zone internal-vr to-zone internal 
policy vr-to-root-vsys {
    match {
        source-address any;
        destination-address any;
        application any;
    }
    then {
        permit;
    }
}


Now test ping again and we can see that packets are encrypted and decrypted.

root@J21-Paris> ping 212.45.63.1 routing-instance internal-vr source 10.225.225.1 count 10 rapid      
PING 212.45.63.1 (212.45.63.1): 56 data bytes
!!!!!!!!!!
--- 212.45.63.1 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 11.881/11.985/12.062/0.050 ms

root@J21-Paris> show security ipsec statistics index 2     
ESP Statistics:
  Encrypted bytes:             1360
  Decrypted bytes:              840
  Encrypted packets:             10
  Decrypted packets:             10
AH Statistics:
  Input bytes:                    0
  Output bytes:                   0
  Input packets:                  0
  Output packets:                 0
Errors:
  AH authentication failures: 0, Replay errors: 0
  ESP authentication failures: 0, ESP decryption failures: 0
  Bad headers: 0, Bad trailers: 0

We have reached the end of policy based VPN as well. I hope I haven’t made any mistake so far. I will continue with traceoptions in which I will do some bunch of IPSEC tunnel troubleshooting.

About: rtoodtoo

Worked for more than 10 years as a Network/Support Engineer and also interested in Python, Linux, Security and SD-WAN // JNCIE-SEC #223 / RHCE / PCNSE


You have a feedback?

Discover more from RtoDto.net

Subscribe now to keep reading and get access to the full archive.

Continue reading