This article describes a configuration example of a primary and backup VPN with route failover using ip-monitoring .
ip-monitoring
Route fail over is achieved using IP-Monitoring.
The following example shows how to configure two route-based VPN tunnels (primary and backup) between two SRX devices.
Configure ISP2 in a virtual routing-instance. To configure a virtual routing-instance, refer to KB16453 - SRX Getting Started - Custom Virtual Router Configuration Example [juniper.net] , RPM probe with target address as ISP1 address (1.1.1.2) and destination-interface as primary VPN's external interface. To configure RPM probes, refer to security-basic-rpm-probe-configuring.html
interfaces { ge-0/0/1 { unit 0 { family inet { address 1.1.1.1/24; >ISP1 Network. } } } fe-0/0/2 { unit 0 { family inet { address 3.3.3.1/24; >ISP2 Network. } } } fe-0/0/3 { unit 0 { family inet { address 192.168.30.2/24; >Ingress Interface Network of SRX1 for PC1. } } } fe-0/0/5 { unit 0 { family inet { address 172.27.201.15/24; } } } st0 { unit 0 { family inet { address 6.6.6.1/24; >Primary Tunnel Network. } } unit 1 { family inet { address 7.7.7.1/24; >Back-up Tunnel Network } } } }
routing-options { static { route 172.27.199.0/24 next-hop 172.27.201.3; route 5.5.5.2/32 next-hop st0.0; route 0.0.0.0/0 next-hop 1.1.1.2; } }
security { ike { proposal ike-phase1-proposal { authentication-method pre-shared-keys; dh-group group2; authentication-algorithm sha1; encryption-algorithm aes-128-cbc; } policy ike-phase1-policy { mode main; proposals ike-phase1-proposal; pre-shared-key ascii-text "$ABC123"; ## SECRET-DATA } gateway gw-srx1 { ike-policy ike-phase1-policy; address 2.2.2.2; >SRX2 Primary Tunnel Address. external-interface ge-0/0/1.0; } gateway gw-srx2 { ike-policy ike-phase1-policy; address 4.4.4.2; >SRX2 Back-up Tunnel Address. external-interface fe-0/0/2.0; } }
ipsec { proposal ipsec-phase2-proposal { protocol esp; authentication-algorithm hmac-sha1-96; encryption-algorithm aes-128-cbc; } policy ipsec-phase2-policy { perfect-forward-secrecy { keys group2; } proposals ipsec-phase2-proposal; } vpn ike-vpn-srx1 { bind-interface st0.0; >Binding Primary Tunnel Interface st0.0 ike { gateway gw-srx1; ipsec-policy ipsec-phase2-policy; } establish-tunnels immediately; } vpn ike-vpn-srx2 { bind-interface st0.1; >Binding Back-up Tunnel Interface st0.1 ike { gateway gw-srx2; ipsec-policy ipsec-phase2-policy; } establish-tunnels immediately; } }
Note: A default permit-all policy is configured below for demonstration purposes only. It can and should be replaced by a more specific policy, matching the customer's environment.
policies { default-policy { permit-all; } }
Security Zones Configuration Note: A simplified zone configuration is provided below for demonstration purposes only. It can and should be replaced by a more restrictive configuration, matching the customer's environment.
zones { security-zone untrust1 { host-inbound-traffic { system-services { all; } protocols { all; } } interfaces { ge-0/0/1.0; } } security-zone untrust2 { host-inbound-traffic { system-services { all; } protocols { all; } } interfaces { fe-0/0/2.0; } } security-zone vpn-srx { host-inbound-traffic { system-services { all; } protocols { all; } } interfaces { st0.0; } } security-zone vpn-srx2 { host-inbound-traffic { system-services { all; } protocols { all; } } interfaces { st0.1; } } security-zone pc1 { host-inbound-traffic { system-services { all; } protocols { all; } } interfaces { fe-0/0/3.0; } } } }
routing-instances { isp2 { instance-type virtual-router; interface fe-0/0/2.0; >Configuring fe-0/0/2.0 of ISP2 Network in virtual-routing instance. routing-options { static { route 0.0.0.0/0 next-hop 3.3.3.2; } } } }
services { rpm { probe example { test test-name { target address 1.1.1.2; >RPM probes test for the target in ISP1. probe-count 3; probe-interval 15; test-interval 10; thresholds { successive-loss 3; total-loss 3; } destination-interface ge-0/0/1.0; next-hop 1.1.1.2; } } }
ip-monitoring { policy test { match { rpm-probe example; } then { preferred-route { route 5.5.5.2/32 { next-hop 7.7.7.2; >Configure st0.1 ip on srx2. } } } } }
interfaces { ge-0/0/0 { unit 0 { family inet { address 5.5.5.1/24; } } } ge-0/0/1 { unit 0 { family inet { address 2.2.2.2/24; } } } fe-0/0/2 { unit 0 { family inet { address 4.4.4.2/24; } } } st0 { unit 0 { family inet { address 6.6.6.2/24; } } unit 1 { family inet { address 7.7.7.2/24; } } } }
To verify, run the following commands:
root@210-4# run show security ike sa >shows phase1 is up for both tunnels. Index State Initiator cookie Responder cookie Mode Remote Address 1323069 UP 2fdfbb7b79a30c62 f9ee530a151c6e76 Main 4.4.4.2 1323111 UP 70d701019d83f829 52ee10f886b38544 Main 2.2.2.2 [edit] root@210-4# run show security ipsec sa >Shows phase2 is up for both the tunnels. Total active tunnels: 2 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <131073 ESP:aes-128/sha1 6a86af86 3387/ unlim - root 500 2.2.2.2 >131073 ESP:aes-128/sha1 1ec5f8c0 3387/ unlim - root 500 2.2.2.2 <131074 ESP:aes-128/sha1 53060f8f 762/ unlim - root 500 4.4.4.2 >131074 ESP:aes-128/sha1 10f0f596 762/ unlim - root 500 4.4.4.2 [edit] root@210-4# run show route 5.5.5.2 inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 5.5.5.2/32 *[Static/5] 00:03:52 > via st0.0
Use the following command to verify what state the route is in based on your ip-monitoring:
root@210-4# run show services ip-monitoring status Policy - test (Status: PASS) RPM Probes: Probe name Test Name Address Status ---------------------- --------------- ---------------- --------- example test-name 1.1.1.2 PASS > Result of the RPM.< Route-Action: route-instance route next-hop state ----------------- ----------------- ---------------- ------------- inet.0 5.5.5.2/32 7.7.7.2 NOT-APPLIED > Action Taken. root@210-4# run show services rpm history-results Owner, Test Probe received Round trip time example, test-name Thu Jun 12 11:38:20 2014 3768 usec example, test-name Thu Jun 12 11:38:35 2014 3090 usec example, test-name Thu Jun 12 11:38:51 2014 3197 usec example, test-name Thu Jun 12 11:39:01 2014 2977 usec example, test-name Thu Jun 12 11:39:16 2014 3076 usec example, test-name Thu Jun 12 11:39:31 2014 4458 usec example, test-name Thu Jun 12 11:39:41 2014 3051 usec root@210-4# run show security flow session destination-prefix 5.5.5.2 Session ID: 9967, Policy name: default-policy-00/2, Timeout: 4, Valid In: 192.168.30.1/900 --> 5.5.5.2/15834;icmp, If: fe-0/0/3.0, Pkts: 1, Bytes: 84 Out: 5.5.5.2/15834 --> 192.168.30.1/900;icmp, If: st0.0, Pkts: 1, Bytes: 84 > Shows that the traffic is passing through Primary Tunnel(st0.0). -------------------------------------------------------------------------------------
Note: When the ISP1 goes down, ping test fails using RPM probes. The traffic then flows through ISP2.
[edit] root@210-4# run show services rpm history-results >Command to get information about received probes and timestamp of the lost connection. Owner, Test Probe received Round trip time example, test-name Thu Jun 12 11:40:36 2014 2902 usec example, test-name Thu Jun 12 11:40:51 2014 3395 usec example, test-name Thu Jun 12 11:41:02 2014 4828 usec example, test-name Thu Jun 12 11:41:17 2014 4959 usec example, test-name Thu Jun 12 11:41:47 2014 Request timed out example, test-name Thu Jun 12 11:42:13 2014 Request timed out example, test-name Thu Jun 12 11:42:28 2014 Request timed out example, test-name Thu Jun 12 11:42:43 2014 Request timed out example, test-name Thu Jun 12 11:43:08 2014 Request timed out example, test-name Thu Jun 12 11:43:23 2014 Request timed out example, test-name Thu Jun 12 11:43:38 2014 Request timed out example, test-name Thu Jun 12 11:44:04 2014 Request timed out example, test-name Thu Jun 12 11:44:19 2014 Request timed out
After it fails, you will be able to see that the new next-hop is in place:
[edit] root@210-4# run show services ip-monitoring status
Policy - test (Status: FAIL) RPM Probes: Probe name Test Name Address Status ---------------------- --------------- ---------------- --------- example test-name 1.1.1.2 FAIL > Result of the RPM. Route-Action: route-instance route next-hop state ----------------- ----------------- ---------------- ------------- inet.0 5.5.5.2/32 7.7.7.2 APPLIED > Action Taken.
[edit] root@210-4# run show route 5.5.5.2
inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both
5.5.5.2/32 *[Static/1] 00:03:03, metric2 0 > to 7.7.7.2 via st0.1 [Static/5] 00:09:05 > via st0.0
[edit] root@210-4# run show security ike sa Index State Initiator cookie Responder cookie Mode Remote Address 4638472 UP 9e8ec577b8447907 0a825f0823113add Main 4.4.4.2 4638471 DOWN c12cb3f915ebfce5 0000000000000000 Main 2.2.2.2 > Primary Tunnel is down. [edit] root@210-4# run show security flow session destination-prefix 5.5.5.2
Session ID: 10415, Policy name: default-policy-00/2, Timeout: 2, Valid In: 192.168.30.1/144 --> 5.5.5.2/15847;icmp, If: fe-0/0/3.0, Pkts: 1, Bytes: 84 Out: 5.5.5.2/15847 --> 192.168.30.1/144;icmp, If: st0.1, Pkts: 1, Bytes: 84 > Shows that the traffic is passing through Back-up Tunnel(st0.1).
Note: IP-monitoring supports only 1 next-hop policy for same route prefix of configured static route. I.E.: If we had a third tunnel (ISP-3), we would add other probes, and then we would add the second policy to route the traffic to 5.5.5.0/24 through the third tunnel (ISP-3). However, then we would have two different policies changing the next hop for the same prefix 5.5.5.0/24. Hence this is not supported.
2020-02-27: minor non-technical edits.