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
- 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
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.
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;
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.
