SRX

Hi,

i have srx 340 series gateway in clustermode  at head office and 300 series gateway at branch side. all branches are connected through aggresive mode and working perfectly. we have now plan to purchase backup line in branhces incase primary down. i wanted to configure backup line as failover in branchside. can anyone help me to configure second line as failover in aggresive mode.

The remote site has a  4G device setup, along with ip-monitoring and an rpm probe to fail the default route over if connectivity goes down on the main WAN. This fails over and back perfectly with internet traffic  however not VPN traffic, as the VPN tunnel is bound to the primary interface.

Attachment(s)

IPSEC Policy.txt   1 KB 1 version

Assuming you have route based vpn you can also use ip monitoring for the vpn failover.

https://kb.juniper.net/InfoCenter/index?page=content&id=KB29227

Another option is to use ospf instead of static routes for your vpn connections. 

have the tunnel interfaces on both sides be ospf neighbors on p2p links 

your lan segments on both sides as passive interfaces

place the backup tunnel as a higher cost link

When the tunnel goes down the ospf neighbor is lost and the route switches to the other tunnel.

Dear Steve Thanks for your suggestion ,

i would like to clear that at remote side ia using aggersive mode by using 4G router as cost effective for company. below is current configuration with RPM and Ip monitoring which is switching internet traffic but not switching VPN interface from ge-0/0/1.0 to ge-0/0/0.0 .

please have a look on below current running configuration

services {
rpm {
probe VPN-ISP {
test VPN-ISP {
probe-type icmp-ping;
target address 8.8.8.8;
probe-count 3;
probe-interval 5;
test-interval 5;
thresholds {
successive-loss 3;
total-loss 3;
}
destination-interface ge-0/0/1.0;
next-hop 192.168.8.1;
}
}
}
application-identification;
ip-monitoring {
policy VPN-ISP {
match {
rpm-probe VPN-ISP;
}
then {
preferred-route {
route 0.0.0.0/0 {
next-hop 192.168.1.1;
}
}
}
}
}
}
security {
log {
mode stream;
report;
}
ike {
policy ike_pol_RUH-HO {
mode aggressive;
proposal-set standard;
pre-shared-key ascii-text "$9$f5QF6/tBRSqmPT3n9CAtu1IE"; ## SECRET-DATA
}
gateway gw_RUH-HO {
ike-policy ike_pol_RUH-HO;
address 1.1.1.2;
dead-peer-detection interval 10;
local-identity user-at-hostname "xxx@abc.com";
external-interface ge-0/0/1.0;
}
}
ipsec {
proposal RUH {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-128-cbc;
lifetime-seconds 3600;
lifetime-kilobytes 4608000;
}
policy ipsec_pol_RUH-HO {
perfect-forward-secrecy {
keys group2;
}
proposals RUH;
}
vpn RUH-HO {
bind-interface st0.1;
ike {
gateway gw_RUH-HO;
proxy-identity {
local 172.16.5.0/24;
remote 172.16.0.0/23;
service any;
}
ipsec-policy ipsec_pol_RUH-HO;
}
establish-tunnels immediately;
}
}
screen {
ids-option untrust-screen {
icmp {
ping-death;
}
ip {
source-route-option;
tear-drop;
}
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
timeout 20;
}
land;
}
}
}
nat {
source {
rule-set nsw_srcnat {
from zone Trust;
to zone Internet;
rule nsw-src-interface {
match {
source-address 0.0.0.0/0;
destination-address 0.0.0.0/0;
}
then {
source-nat {
interface;
}
}
}
}
}
}
policies {
from-zone Trust to-zone Internet {
policy All_Trust_Internet {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
policy Trust-Internet {
match {
source-address RUH-LAN;
destination-address any;
application Allow_ports;
}
then {
permit;
}
}
}
from-zone Trust to-zone HO {
policy RUH-HO {
match {
source-address RUH-LAN;
destination-address HO;
application any;
}
then {
permit;
}
}
}
from-zone HO to-zone Trust {
policy HO-RUH {
match {
source-address HO;
destination-address RUH-LAN;
application any;
}
then {
permit;
}
}
}
}
zones {
security-zone Trust {
address-book {
address RUH-LAN 172.16.5.0/24;
address DVR 172.16.5.42/32;
}
host-inbound-traffic {
system-services {
all;
}
}
interfaces {
ge-0/0/4.0 {
host-inbound-traffic {
system-services {
ping;
https;
telnet;
http;
}
}
}
}
}
security-zone Internet {
host-inbound-traffic {
system-services {
https;
ike;
ssh;
ping;
}
}
interfaces {
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
ping;
}
}
}
ge-0/0/1.0;
}
}
security-zone HO {
address-book {
address HO 172.16.0.0/23;
}
host-inbound-traffic {
system-services {
ike;
}
}
interfaces {
st0.1;
}
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 192.168.1.2/24;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 192.168.8.2/24;
}
}
}
ge-0/0/4 {
unit 0 {
family inet {
filter {
input internet;
}
address 172.16.5.254/24;
}
}
}
st0 {
unit 1 {
family inet;
}
}
}
routing-options {
static {
route 172.16.0.0/23 next-hop st0.1;
route 0.0.0.0/0 {
next-hop 192.168.8.1;
qualified-next-hop 192.168.1.1 {
preference 6;
}
}
}
}
protocols {
l2-learning {
global-mode switching;
}
rstp {
interface all;
}
}
policy-options {
policy-statement import-direct {
term 1 {
from {
instance master;
protocol direct;
}
then accept;
}
term default {
then reject;
}
}
}
firewall {
filter internet {
term VPN {
from {
destination-address {
172.16.0.0/23;
172.16.5.254/32;
}
}
then accept;
}
term 1 {
from {
protocol tcp;
port [ 80 443 110 53 995 ];
}
then {
routing-instance http-internet;
}
}
term 2 {
then accept;
}
}
}
routing-instances {
http-internet {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 {
next-hop 192.168.1.1;
qualified-next-hop 192.168.8.1 {
preference 6;
}
}
}
instance-import import-direct;
}

Hello,

---

@WaseemR wrote:

current configuration with RPM and Ip monitoring which is switching internet traffic but not switching VPN interface from ge-0/0/1.0 to ge-0/0/0.0 .

  

 I would go out on a limb and suggest You don't need to.

Unless You are constrained by the number of simultaneously active tunnels on the hub or use metered connections, keep all tunnels active all the time, run a dynamic routing protocol inside Your tunnels (Steve suggested OSPF but I would vouch for BGP) and manipulate metrics/local preference to route traffic in/out of the tunnels.

I did designs like this before and they do actually work in production.

HTH

Thx
Alex

Hi Alex,

i have only single tunnel connected throug 4G LTE. is there any no option to redirect traffic to another internet link ISP2 automatically if 4GLTE ISP1 link is down through RPM. as i stated above that internet traffic like http pop etc swtiched automatically from ISP1 to ISP2 connection once ISP1 down but VPN interface of internet connection doesnot . i hope you can understand my query which is very simple. do i really need to configure two tunnel. is it not possible to just switch internet interface to another ISP as both interface have dynamic IP and IPSEC connection is by aggersive mode not through Main Mode. please  have a look in my current configuration.

Thanks for your time 

For any kind of failover you must create two vpn tunnels.  Part of your vpn gateway configuration is to choose the outgoing interface that the tunnel binds to.  That will change from isp1 to isp2 when you do failover so you need the second tunnel using this interface configured and ready to come up when the failover occurs.

Hello Everyone ,

sorry for delay in reply, i reached to final configuration with automatic change default gateway while changing IPSEC interface. internet services also swtichign automatically. no need to create two tunnel just need to change external interface only to work VPN on another WAN if primary goes down. here is configuration which will may help others.

services {
rpm {
probe probe-isp1 {
test test-isp1 {
probe-type icmp-ping;
target address 8.8.8.8;
probe-count 3;
probe-interval 5;
test-interval 5;
thresholds {
successive-loss 3;
total-loss 3;
}
destination-interface ge-0/0/0.0;
next-hop 192.168.10.1;
}
}
probe probe-isp2 {
test test-isp2 {
probe-type icmp-ping;
target address 8.8.8.8;
probe-count 3;
probe-interval 5;
test-interval 5;
thresholds {
successive-loss 3;
total-loss 5;
}
destination-interface ge-0/0/1.0;
next-hop 192.168.8.1;
}
}
}
ip-monitoring {
policy track-isp1 {
match {
rpm-probe probe-isp1;
}
then {
preferred-route {
routing-instances ISP1 {
route 0.0.0.0/0 {
next-hop 192.168.8.1;
}
}
}
}
}
policy track-isp2 {
match {
rpm-probe probe-isp2;
}
then {
preferred-route {
routing-instances ISP2 {
route 0.0.0.0/0 {
next-hop 192.168.10.1;
}
}
}
}
}
}
}

routing-options {
static {
route 0.0.0.0/0 next-table ISP1.inet.0;
route 172.16.0.0/23 next-hop st0.1;
}
rib-groups {
ISP1-to-ISP2 {
import-rib [ ISP1.inet.0 ISP2.inet.0 ];
}
ISP2-to-ISP1 {
import-rib [ ISP2.inet.0 ISP1.inet.0 ];
}
}
}
routing-instances {
ISP1 {
instance-type virtual-router;
interface ge-0/0/0.0;
routing-options {
interface-routes {
rib-group inet ISP1-to-ISP2;
}
static {
route 0.0.0.0/0 next-hop 192.168.10.1;
}
}
}
ISP2 {
instance-type virtual-router;
interface ge-0/0/1.0;
routing-options {
interface-routes {
rib-group inet ISP2-to-ISP1;
}
static {
route 0.0.0.0/0 next-hop 192.168.8.1;
}
}
}
}