Expanding on the basic branch setup from my previous labs, I added another virtual SRX to the topology to exercise the VPN stuff. As the “ISP” router, I first tried adding a CSR-1000V to the lab but found out the hard way that it’s bandwidth throttled at 100kbps. With six virtual machines behind it sporadically fetching stuff off the internet, the entire lab came to a grinding halt. 🙂
As a quick workaround, I settled on a VyOS appliance , which was surprisingly easy to work with. It’s very similar to JunOS so I had it up and running in just a couple of minutes.
Anyway, enough about that. Here’s the network I’ll be working off to build some VPNs…
Topology
Before you configure VPN tunnels, make sure that your public interface is listening for IKE traffic. This is defined on the zone or interface level.
[edit security zones security-zone untrust]
root@NP-vSRX-01# show
host-inbound-traffic {
system-services {
ssh;
ping;
ike;
}
}
interfaces {
ge-0/0/0.0;
}
Tunnel interface, routing and security zone
First, define a Secure Tunnel interface with IPv4 support by adding the inet family. If you forget the family inet statement, your tunnel will not pass traffic.
For simple tunnels without dynamic routing protocols, assigning an IP address is not required.
[edit interfaces]
root@NP-vSRX-01# show st0
unit 1 {
description "Branch1 Tunnel Interface";
family inet;
}
Create a static route for the peer subnet(s) and point it to the tunnel interface.
[edit] root@NP-vSRX-01# set routing-options static route 10.2.0.0/24 next-hop st0.1
One thing I tend to forget is to add the st0 interface to the right security zone. Rather than putting it in the untrust zone, I will create a separate zone for VPN and put the tunnel there.
[edit security zones security-zone vpn]
root@NP-vSRX-01# show
interfaces {
st0.1;
}
Once that is done, we can start configuring the actual VPN policy. There are a lot of components to configure, but once you know how they intertwine it’s pretty straightforward.
Configuring Phase 1
First, configure an IKE proposal. You could choose one of the JunOS templates, but where’s the fun in that, right? 🙂
[edit security ike]
root@NP-vSRX-01# show
proposal P1-Proposal-Branch1 {
description "Branch1 Phase1 Proposal";
authentication-method pre-shared-keys;
authentication-algorithm sha-256;
encryption-algorithm aes-256-cbc;
lifetime-seconds 43200;
}
Once we have the P1 proposal, we define the phase 1 policy which in turn refers to the proposal. Unless your peer has a dynamic IP, main mode is what you need. This is also where you specify the preshared key.
[edit security ike policy P1-Policy-Branch1] root@NP-vSRX-01# show mode main; description "Branch1 Phase1 Policy"; proposals P1-Proposal-Branch1; pre-shared-key ascii-text "$9$DDH.f9CuB1hqMORhcle4aZGjq"; ## SECRET-DATA
Third and last for Phase 1 template, configure the gateway peer IP address with the corresponding policy. If possible, always use IKE version 2. The external interface is where the SRX can expect the UDP/500 packets.
[edit security ike gateway P1-Peer-Branch1] root@NP-vSRX-01# show ike-policy P1-Policy-Branch1; address 2.2.2.1; external-interface ge-0/0/0; version v2-only;
Now that Phase1 is set, we can move on to the IPsec configuration.
Phase 2 – IPsec
Just as we did before, we first define a proposal. Choose your most secure option for encryption and hashing, and a reasonably short keying lifetime.
[edit security ipsec proposal P2-Proposal-Branch1] root@NP-vSRX-01# show description "Branch1 Phase2 Proposal"; protocol esp; authentication-algorithm hmac-sha-256-128; encryption-algorithm aes-256-cbc; lifetime-seconds 3600;
Configure the IPsec policy that again refers to the proposal. Unless the peer does not support it, always turn on PFS.
[edit security ipsec policy P2-Policy-Branch1]
root@NP-vSRX-01# show
description "Branch1 Phase2 Policy";
perfect-forward-secrecy {
keys group5;
}
proposals P2-Proposal-Branch1;
The final step is where the Phase 1 and 2 components are glued together. For route-based tunnels, don’t forget to bind your st interface. I prefer to negotiate the tunnels immediately rather than waiting for traffic.
[edit security ipsec vpn P2-IPsec-Branch1]
root@NP-vSRX-01# show
bind-interface st0.1;
ike {
gateway P1-Peer-Branch1;
ipsec-policy P2-Policy-Branch1;
}
establish-tunnels immediately;
Security Policies
From a VPN point of view, we are ready to accept IPsec connections on this box. We are listening for IKE traffic, we have a route pointing to our tunnel interface and VPN policies are configured. The only thing we need to do is configure the firewall policies.
For this one, I will be allowing traffic from the remote sites to one of the machines on the trust zone. I already created some objects in the global address book.
From VPN to Trust:
[edit security policies from-zone vpn to-zone trust]
root@NP-vSRX-01# show
policy FW-Allow-VPN-Branch {
match {
source-address Host-10.2.0.10;
destination-address Host-10.0.0.10;
application any;
}
then {
permit;
count;
}
}
From Trust to VPN:
[edit security policies]
root@NP-vSRX-01# show from-zone trust to-zone vpn
policy FW-Allow-VPN-Branch {
match {
source-address Host-10.0.0.10;
destination-address Host-10.2.0.10;
application any;
}
then {
permit;
count;
}
}
Configuring the Branch site SRX
The benefit of having two SRX’s is that you can easily copy-paste, edit and mirror the config.
### PHASE 1 ### set security ike proposal P1-Proposal-HQ description "HQ Phase1 Proposal" set security ike proposal P1-Proposal-HQ authentication-method pre-shared-keys set security ike proposal P1-Proposal-HQ authentication-algorithm sha-256 set security ike proposal P1-Proposal-HQ encryption-algorithm aes-256-cbc set security ike proposal P1-Proposal-HQ lifetime-seconds 43200 set security ike policy P1-Policy-HQ mode main set security ike policy P1-Policy-HQ description "HQ Phase1 Policy" set security ike policy P1-Policy-HQ proposals P1-Proposal-HQ set security ike policy P1-Policy-HQ pre-shared-key ascii-text "$9$DDH.f9CuB1hqmORhcle4aZGjq" set security ike gateway P1-Peer-HQ ike-policy P1-Policy-HQ set security ike gateway P1-Peer-HQ address 1.1.1.1 set security ike gateway P1-Peer-HQ external-interface ge-0/0/0 ### PHASE 2 #### set security ipsec proposal P2-Proposal-HQ description "HQ Phase2 Proposal" set security ipsec proposal P2-Proposal-HQ protocol esp set security ipsec proposal P2-Proposal-HQ authentication-algorithm hmac-sha-256-128 set security ipsec proposal P2-Proposal-HQ encryption-algorithm aes-256-cbc set security ipsec proposal P2-Proposal-HQ lifetime-seconds 3600 set security ipsec policy P2-Policy-HQ description "HQ Phase2 Policy" set security ipsec policy P2-Policy-HQ perfect-forward-secrecy keys group5 set security ipsec policy P2-Policy-HQ proposals P2-Proposal-HQ set security ipsec vpn P2-IPsec-HQ bind-interface st0.1 set security ipsec vpn P2-IPsec-HQ ike gateway P1-Peer-HQ set security ipsec vpn P2-IPsec-HQ ike ipsec-policy P2-Policy-HQ #### TUNNEL INTERFACE ### set interfaces st0 unit 1 description "HQ Tunnel Interface" set interfaces st0 unit 1 family inet ### HOST INBOUND TRAFFIC ### set security zones security-zone untrust host-inbound-traffic system-services ike ### ADD TUNNEL TO ZONE ### set security zones security-zone untrust interfaces st0.1 ### ADD ROUTE ### set routing-options static route 10.0.0.0/24 next-hop st0.1 set routing-options static route 10.0.4.0/24 next-hop st0.1 ### SECURITY POLICIES ### set security policies from-zone vpn to-zone branch policy FW-Allow-VPN-HQ-In match source-address Host-10.0.0.10 set security policies from-zone vpn to-zone branch policy FW-Allow-VPN-HQ-In match destination-address Host-10.2.0.10 set security policies from-zone vpn to-zone branch policy FW-Allow-VPN-HQ-In match application any set security policies from-zone vpn to-zone branch policy FW-Allow-VPN-HQ-In then permit set security policies from-zone vpn to-zone branch policy FW-Allow-VPN-HQ-In then count set security policies from-zone branch to-zone vpn policy FW-Allow-VPN-HQ-Server match source-address Host-10.2.0.10 set security policies from-zone branch to-zone vpn policy FW-Allow-VPN-HQ-Server match destination-address Host-10.0.0.10 set security policies from-zone branch to-zone vpn policy FW-Allow-VPN-HQ-Server match application any set security policies from-zone branch to-zone vpn policy FW-Allow-VPN-HQ-Server then permit set security policies from-zone branch to-zone vpn policy FW-Allow-VPN-HQ-Server then count
Verification
On the HQ SRX, we already have a phase 1 tunnel up using IKEv2 as the exchange protocol.
root@NP-vSRX-01> show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 2441630 UP 2fb27eba88550b6b e8b7c6a94c94f8d2 IKEv2 2.2.2.1
We also have a Phase 2 tunnel, with just under one hour of lifetime left.
root@NP-vSRX-01> show security ipsec security-associations Total active tunnels: 1 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <131073 ESP:aes-cbc-256/sha256 14b32bcb 3433/ unlim - root 500 2.2.2.1 >131073 ESP:aes-cbc-256/sha256 fef69f20 3433/ unlim - root 500 2.2.2.1
Some more details about the IPsec parameters, like Proxy IDs (0.0.0.0/0) and encryption/authentication standards.
root@NP-vSRX-01> show security ipsec security-associations index 131073 detail
ID: 131073 Virtual-system: root, VPN Name: P2-IPsec-Branch1
Local Gateway: 1.1.1.1, Remote Gateway: 2.2.2.1
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)
Version: IKEv2
DF-bit: clear
Bind-interface: st0.1
Port: 500, Nego#: 32, Fail#: 0, Def-Del#: 0 Flag: 0x600a29
Last Tunnel Down Reason: Delete payload received
Direction: inbound, SPI: 14b32bcb, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 3339 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2752 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (256 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Direction: outbound, SPI: fef69f20, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 3339 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2752 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (256 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
A good way to verify that there’s two-way communication is to inspect the IPsec counters
root@NP-vSRX-01> show security ipsec statistics index 131073 ESP Statistics: Encrypted bytes: 140965904 Decrypted bytes: 3342178434 Encrypted packets: 1132200 Decrypted packets: 2245688 AH Statistics: Input bytes: 0 Output bytes: 0 Input packets: 0 Output packets: 0 Errors: AH authentication failures: 0, Replay errors: 251 ESP authentication failures: 0, ESP decryption failures: 0 Bad headers: 0, Bad trailers: 0
The ultimate test is to verify on the internal machines. Note the asterisks on the tunnel segment. If there’s an address assigned to the st interface, this one would show in the trace results.
root@Branch-vSRX-01> ssh lab@10.2.0.10 lab@10.2.0.10's password: Welcome to Ubuntu 14.10 (GNU/Linux 3.16.0-23-generic x86_64) * Documentation: https://help.ubuntu.com/ Last login: Thu Sep 10 22:27:33 2015 lab@V120-10:~$ ping 10.0.0.10 PING 10.0.0.10 (10.0.0.10) 56(84) bytes of data. 64 bytes from 10.0.0.10: icmp_seq=1 ttl=62 time=10.3 ms 64 bytes from 10.0.0.10: icmp_seq=2 ttl=62 time=13.5 ms 64 bytes from 10.0.0.10: icmp_seq=3 ttl=62 time=11.6 ms ^C --- 10.0.0.10 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 10.370/11.869/13.567/1.318 ms lab@V120-10:~$ traceroute 10.0.0.10 traceroute to 10.0.0.10 (10.0.0.10), 30 hops max, 60 byte packets 1 10.2.0.1 (10.2.0.1) 3.864 ms 3.912 ms 4.003 ms 2 * * * 3 10.0.0.10 (10.0.0.10) 13.682 ms 13.679 ms 13.666 ms lab@V120-10:~$
That’s it, a fully functional, although very basic, route-based VPN.