This is the second post in the Policy-Based VPN series. In our first post we configured a policy-based VPN using security policies tied to the UNTRUST interface. For this post, we will be using a route-based configuration that allows interoperability to the remote side configured as a policy-based VPN. This will also allow us to define a dedicated security zone for the VPN, hence helping to increase security. What we will be using in this post are proxy IDs to define local and remote networks.

The first part of this post is the setup of the labs, just like we did last time. If you want, you can skip down to where we delete the old configuration to see how the new configuration is done.

To recap, there are four different VPN configurations in this series:

Again, I will be using Juniper vLabs IPSEC VPN Policy-based lab for these posts. Feel free to head on over there and spin the lab up yourself when you are ready and kick the tires on these different configurations. Below is our diagram for the lab topology.

Just like last time, we will only be looking at vSRX1 for our configurations and using the vMX to test our connectivity. To connect to the console on the devices, hover over the device and click on the down-arrow that appears and then select SSH. Once you do that you should have a new tab opened up that has the CLI of the SRX open.

Once you are connected, feel free to look around as this lab is preconfigured. Yet for the sake of this blog and learning, I would suggest that you just delete the security ike, IPsec, and policy sections entirely and re-create it with me. Please note that for this post we will also delete routing-options as we need to route the interesting traffic differently.

jcluser@vSRX1> edit 
Entering configuration mode

[edit]
jcluser@vSRX1# delete security ike

[edit]
jcluser@vSRX1# delete security ipsec

[edit]
jcluser@vSRX1# delete security policies

[edit]
jcluser@vSRX1# delete routing-options

jcluser@vSRX1# commit 
commit complete

The IKE and IPSEC information for this lab is as follows:

IKE: 
     main mode
     proposal default
     pre-shared key password
     peer IP 10.100.12.2

IPSEC: 
     proposal default

Tunneled Networks:
     local: 10.100.11.0/24
     remote: 10.100.22.0/24

So now we can create our IKE and IPSEC policies for this lab. We will use the same initial IKE and IPSEC policy as our last lab.

set security ike proposal IKE-PROP authentication-method pre-shared-keys

set security ike policy IKE-POL mode main
set security ike policy IKE-POL proposals IKE-PROP
set security ike policy IKE-POL pre-shared-key ascii-text password

set security ike gateway vSRX2 ike-policy IKE-POL
set security ike gateway vSRX2 address 10.100.12.2
set security ike gateway vSRX2 external-interface ge-0/0/1

set security ipsec proposal IPSEC-PROP

set security ipsec policy IPSEC-POL proposals IPSEC-PROP

set security ipsec vpn VPN-to-vSRX ike gateway vSRX2
set security ipsec vpn VPN-to-vSRX ike ipsec-policy IPSEC-POL
set security ipsec vpn VPN-to-vSRX establish-tunnels immediately

Here is where things start to be different between policy-based and route-based. VPNs. We will need to use proxy-IDs for the tunnel.

Since we are not using a security policy with a tunnel action, we need to specify the proxy-id in the configuration. These are the interesting networks that are to be sent over the encrypted tunnel. Remember, these need to match exactly on both sides in order for the tunnels to come up.

This configuration is done under ipsec vpn [VPN-NAME] ike proxy-identity. The local keyword specifies the local subnet ( 10.100.11.0/24 ) and remote is the remote subnet ( 10.100.22.0/24 ).

set security ipsec vpn VPN-to-vSRX ike proxy-identity local 10.100.11.0/24
set security ipsec vpn VPN-to-vSRX ike proxy-identity remote 10.100.22.0/24

Now that we have configured that, we need to also bind the VPN to an st (standard tunnel) interface. These all start at st0.x and are configured like any other interface in Junos. For this lab, we will just use st0.0.

set security ipsec vpn VPN-to-vSRX bind-interface st0.0

You do not need to assign an IP address to the interface (you can if you want) yet you do need to configure it with family inet. If you do not configure family inet and try to pass traffic over it, you will go crazy trying to figure out what is wrong. Trust me – I know.

set interfaces st0 unit 0 family inet

The next step is to tell the SRX how to get to the remote network, here we will use a static route for the 10.100.22.0/24 subnet. We will point the route at the st0.0 interface (the interface bound for this VPN). If you used an IP address, you would set the next-hop to the interface IP.

set routing-options static route 10.100.22.0/24 next-hop st0.0

Like the policy-based VPN, we do need to configure security policies as well as a security zone. You could place the st0.0 interface in the UNTRUST zone and use those policies if you wanted to, yet all the deployments I have seen, the st0.0 interfaces are placed in a dedicated VPN or common VPN zone. Common zones are used for same company VPNs whereas dedicated are usually Business to Business (B2B) VPNs. For this lab, we will create a dedicated VPN zone just for this traffic.

The first thing we need to do is create the zone and assign the st0.0 interface to that zone. Here we will use the VPN zone.

set security zones security-zone VPN interfaces st0.0

As with any other Junos based zone-to-zone traffic, we need to create the appropriate security policies. For this lab that is trust to VPN and VPN to trust.

Now if you recall, the lab has some pre-configured address-books for the local and remote subnets (Site-A and Site-B). If you look at the configuration provided, you will see that Site-B is attached to the zone untrust.

set security address-book Site-A address Site-A-Net 10.100.11.0/24
set security address-book Site-A attach zone trust
set security address-book Site-B address Site-B-Net 10.100.22.0/24
set security address-book Site-B attach zone untrust

Since we are now going to access Site-B over a different zone, we will need to attach that address-book entry to the VPN zone as well.

set security address-book Site-B attach zone VPN

Now we can configure our policy from the trust zone to the VPN zone. We will match our local subnet, remote subnet, and all traffic to keep it simple.

set security policies from-zone trust to-zone VPN policy PERMIT-ALL match source-address Site-A-Net
set security policies from-zone trust to-zone VPN policy PERMIT-ALL match destination-address Site-B-Net
set security policies from-zone trust to-zone VPN policy PERMIT-ALL match application any
set security policies from-zone trust to-zone VPN policy PERMIT-ALL then permit

Now if we want to permit return traffic, we need to create another policy that is from the VPN zone to the trust zone.

set security policies from-zone VPN to-zone trust policy PERMIT-ALL match source-address Site-B-Net
set security policies from-zone VPN to-zone trust policy PERMIT-ALL match destination-address Site-A-Net
set security policies from-zone VPN to-zone trust policy PERMIT-ALL match application any
set security policies from-zone VPN to-zone trust policy PERMIT-ALL then permit

Once that is all committed, the VPN should establish and you should see a route for the 10.100.22.0/24 subnet in your inet.0 table

jcluser@vSRX1> show route 10.100.22.0 

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

10.100.22.0/24     *[Static/5] 00:48:25
                      to 10.100.12.2 via ge-0/0/1.0
                    > via st0.0

jcluser@vSRX1> 

Once we have the route confirmed, we can try and PING from vMX1

jcluser@Host1> ping 10.100.22.2 rapid 
PING 10.100.22.2 (10.100.22.2): 56 data bytes
!!!!!
--- 10.100.22.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.324/2.014/3.659/0.843 ms

jcluser@Host1> 

Success! Now we can go look at our ike sa and ipsec sa.

jcluser@vSRX1> show security ike sa 
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address   
1108874 UP     7af171370e5b1695  a5a200361cf0520a  Main           10.100.12.2     

jcluser@vSRX1> show security ike security-associations detail 
IKE peer 10.100.12.2, Index 1108874, Gateway Name: vSRX2
  Role: Initiator, State: UP
  Initiator cookie: 7af171370e5b1695, Responder cookie: a5a200361cf0520a
  Exchange type: Main, Authentication method: Pre-shared-keys
  Local: 10.100.12.1:500, Remote: 10.100.12.2:500
             <--- OUTPUT REMOVED TO MAKE IT EASIER TO READ --->
    Local: 10.100.12.1:500, Remote: 10.100.12.2:500
    Local identity: 10.100.12.1
    Remote identity: 10.100.12.2

As you can see from the IPSEC SA detail output, we show the local identities for the tunnel (10.100.11.0/24 and 10.100.22.0/24).


jcluser@vSRX1> show security ipsec sa                            
  Total active tunnels: 1     Total Ipsec sas: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway   
  <131073 ESP:3des/sha1 5a61551e 3519/ unlim   -   root 500   10.100.12.2     
  >131073 ESP:3des/sha1 570b201  3519/ unlim   -   root 500   10.100.12.2     

jcluser@vSRX1> show security ipsec sa detail 
ID: 131073 Virtual-system: root, VPN Name: VPN-to-vSRX
  Local Gateway: 10.100.12.1, Remote Gateway: 10.100.12.2
  Local Identity: ipv4_subnet(any:0,[0..7]=10.100.11.0/24)
  Remote Identity: ipv4_subnet(any:0,[0..7]=10.100.22.0/24)
  Version: IKEv1
              <--- OUTPUT REMOVED TO MAKE IT EASIER TO READ --->

Now one nice thing with route-based VPNs is that it is easier to see the traffic over the VPN. Since we have a dedicated interface assigned to this VPN, we can check the flows on that interface and see what is going over the tunnel – here we have SSH traffic (port 22).

jcluser@vSRX1> show security flow session interface st0.0    
Total sessions: 0

jcluser@vSRX1> show security flow session interface st0.0    
Session ID: 80, Policy name: PERMIT-ALL/8, Timeout: 1796, Valid
  In: 10.100.11.2/57448 --> 10.100.22.2/22;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 15, Bytes: 2733, 
  Out: 10.100.22.2/22 --> 10.100.11.2/57448;tcp, Conn Tag: 0x0, If: st0.0, Pkts: 11, Bytes: 2261, 
Total sessions: 1

If you have more then one interesting network that needs to go over the same IKE/IPSEC pair, you will need to create just ipsec vpn portion of the config for each subnet pair. While it will not work in this lab, the configuration for 10.100.111.0/24 and 10.100.222.0/24 would look like:

vpn VPN-to-vSRX-Tunnel-2 {
            bind-interface st0.0;
            ike {
                gateway vSRX2;
                proxy-identity {
                    local 10.100.111.0/24;
                    remote 10.100.222.0/24;
                }
                ipsec-policy IPSEC-POL;
            }
        }        

routing-options {
    static {
        route 10.100.222.0/24 next-hop st0.0;
    }
}       

The next post will cover the preferred way of configuring policy-based VPNs on Juniper, traffic-selectors.

The complete output for what this post covered is below.


security {
    ike {
        proposal IKE-PROP {
            authentication-method pre-shared-keys;
        }
        policy IKE-POL {
            mode main;
            proposals IKE-PROP;
            pre-shared-key ascii-text "$9$V.bgJGUHm5FjHBEyKx7jHq.PQ"; ## SECRET-DATA
        }
        gateway vSRX2 {
            ike-policy IKE-POL;
            address 10.100.12.2;
            external-interface ge-0/0/1;
        }
    }
    ipsec {
        proposal IPSEC-PROP;
        policy IPSEC-POL {
            proposals IPSEC-PROP;
        }
        vpn VPN-to-vSRX {
            bind-interface st0.0;
            ike {
                gateway vSRX2;
                proxy-identity {
                    local 10.100.11.0/24;
                    remote 10.100.22.0/24;
                }
                ipsec-policy IPSEC-POL;
            }
        }
    }
    address-book {
        Site-A {
            address Site-A-Net 10.100.11.0/24;
            attach {
                zone trust;
            }
        }
        Site-B {
            address Site-B-Net 10.100.22.0/24;
            attach {
                zone untrust;
                zone VPN;
            }
        }
    }
    policies {
        from-zone trust to-zone VPN {       
            policy PERMIT-ALL {
                match {
                    source-address Site-A-Net;
                    destination-address Site-B-Net;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone VPN to-zone trust {
            policy PERMIT-ALL {
                match {
                    source-address Site-B-Net;
                    destination-address Site-A-Net;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
    } 
    zones {
        security-zone trust {
            host-inbound-traffic {
                system-services {
                    all;
                }
            }
            interfaces {
                ge-0/0/0.0;
            }
        }
        security-zone untrust {
            host-inbound-traffic {
                system-services {
                    ike;
                }
            }
            interfaces {
                ge-0/0/1.0;
            }
        }
        security-zone VPN {
            interfaces {
                st0.0;                      
            }
        }
    }
}
interfaces {
    st0 {
        unit 0 {
            family inet;                
        }
    }
}
routing-options {
    static {
        route 10.100.22.0/24 next-hop st0.0;
    }
}