SRX Services Gateway
Highlighted
SRX Services Gateway

VPN Redundancy with dual ISP

‎12-15-2013 10:33 AM

Hi,

 

I've been trying to get my head around setting up VPN redundancy for remote sites connecting back to Head Office. I've looked through various documentation but haven't been successful in setting this up.

 

All remote sites have SRX100 installed with dual ISPs - using built in vdsl and using interface fe-0/0/7.0 for the second ISP. Both are in the untrust zone and connections established ok. At the head office, we have a netscreen NS-50 terminating all the VPN tunnels from the remote sites. Using route based VPNs and internet connectivity provided by separate ISPs.

 

So obviously I have configurations to do at both ends to achieve this. Question:

 

1) At the head office, I have created another VPN i.e RemoteSite_Failover and at the remote site have configured the same and established another vpn tunnel. At the head office, I created a second static route to the same remote site subnet with a preference value set higher than the first static route. Is this correct? 

 

2) At the remote site, I have no problem failing over to the second ISP for internet traffic, but not sure how to configure for failover VPN.

 

Any help is greatly appecriated. Thank You!

7 REPLIES 7
Highlighted
SRX Services Gateway

Re: VPN Redundancy with dual ISP

‎12-15-2013 06:31 PM

AArrghh - spent all day on this, starting to do my head in 🙂

 

I can get both VPN tunnels up and running, only one at a time though as I have to manuall change the static route 0.0.0.0/0 to ISP2 

 

Problem is I have to do this  manually and also all the other static routes are defined to go out over tunnel st0.1, but if ISP2 is active, all these static routes need to go out over the second vpn tunnel st0.2 which uses ISP2.

 

I'll have another go tomorrow, hope someone can help me with this ot I'll be at it every night 🙂 Thank You!

Highlighted
SRX Services Gateway

Re: VPN Redundancy with dual ISP

‎12-15-2013 10:57 PM

 

you can set a static router for you vpn endpoint over your second ISP.  You could use OSPF for the static routes over the VPN.  http://kb.juniper.net/InfoCenter/index?page=content&id=KB22392

 

If your public VPN endpoint for both tunnels is the same you could use IP MONITORING WITH FBF see http://kb.juniper.net/InfoCenter/index?page=content&id=KB22052

 

 

 

Marc



-----------------------------------------------------------------
Please Mark My Solution Accepted if it Helped, Kudos are Appreciated Too
-----------------------------------------------------------------
Highlighted
SRX Services Gateway

Re: VPN Redundancy with dual ISP

‎12-22-2013 05:50 AM

Hi Marc,

 

Im making progress, I have got the dual ISP working but only works for traffic going to the untrust zone. Static route:

 

routing-options {
static {
route 0.0.0.0/0 {
next-hop pp0.0;
qualified-next-hop at-1/0/0.0 {
preference 7;
}
preference 5;
}

route 192.168.2.0/24 next-hop st0.1;
route 192.168.3.0/24 next-hop st0.2;

}

}

 

So as you can see the preferred route out is pp0.0 and if that fails then use the adsl at-1/0/0.0 but the vpns won't work as  im not sure what next steps i need to take. So I created 4 VPN tunnels:

 

st0.1 ( 192.168.2.0/24 traffic should go out VPN tunnel which is bound to  PP0.0 - the preferred ISP)

st0.2 192.168.3.0/24 traffic should go out VPN tunnel which is bound to  PP0.0 - the preferred ISP)

 

If pp0.0 fails then use the other failover tunnels:

 

st0.3 192.168.2.0/24 traffic should go out VPN tunnel which is bound to  AT-1/0/0.0 - the failover ISP)

st0.4 192.168.2.0/24 traffic should go out VPN tunnel which is bound to  AT-1/0/0.0 - the failover ISP)

 

My config for the 4 VPN Tunnels are:

ike {
proposal ScreenOS-Standard {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
lifetime-seconds 28800;
}
policy ike-Tunnel-UK-PP {
mode main;
proposal-set standard;
pre-shared-key ascii-text "sharedkey";
}
policy ike-Tunnel-US-PP {
mode main;
proposals ScreenOS-Standard;
pre-shared-key ascii-text "sharedkey";
}
policy ike-Tunnel-UK-AT {
mode main;
proposal-set standard;
pre-shared-key ascii-text "sharedkey";
}
policy ike-Tunnel-US-AT {
mode main;
proposals ScreenOS-Standard;
pre-shared-key ascii-text "sharedkey";
}
gateway Tunnel-UK-PP-Phase1 {
ike-policy ike-Tunnel-UK-PP;
address 1.1.1.1;
external-interface pp0.0;
}
gateway Tunnel-US-PP-Phase1 {
ike-policy ike-Tunnel-US-PP;
address 2.2.2.2;
external-interface pp0.0;
}
gateway Tunnel-UK-AT-Phase1 {
ike-policy ike-Tunnel-UK-AT;
address 1.1.1.1;
external-interface at-1/0/0;
}
gateway Tunnel-US-AT-Phase1 {
ike-policy ike-Tunnel-US-AT;
address 2.2.2.2;
external-interface at-1/0/0;
}
}
ipsec {
proposal ScreenOS-Standard {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 3600;
}
policy P2-ScreenOS-Standard {
proposal-set standard;
}
vpn Tunnel-UK-PP-Phase2 {
bind-interface st0.1;
vpn-monitor {
optimized;
}
ike {
gateway Tunnel-UK-PP-Phase1;
ipsec-policy P2-ScreenOS-Standard;
}
establish-tunnels immediately;
}
vpn Tunnel-US-PP-Phase2 {
bind-interface st0.2;
vpn-monitor {
optimized;
}
ike {
gateway Tunnel-US-PP-Phase1;
ipsec-policy P2-ScreenOS-Standard;
}
establish-tunnels immediately;
}
vpn Tunnel-UK-AT-Phase2 {
bind-interface st0.3;
vpn-monitor {
optimized;
}
ike {
gateway Tunnel-UK-AT-Phase1;
ipsec-policy P2-ScreenOS-Standard;
}
establish-tunnels immediately;
}
vpn Tunnel-US-AT-Phase2 {
bind-interface st0.4;
vpn-monitor {
optimized;
}
ike {
gateway Tunnel-US-AT-Phase1;
ipsec-policy P2-ScreenOS-Standard;
}
establish-tunnels immediately;
}
}

 

 

So I was thinking could I do this with routing options? I didnt try it as I dont think its the right way to achieve this for example:

 

static {
route 192.168.1.0/24 {
next-hop st0.1;
qualified-next-hop st0.3 {
preference 7;
}
preference 5;
}

 

etc... but that seems a little crude? 

Highlighted
SRX Services Gateway

Re: VPN Redundancy with dual ISP

‎12-22-2013 07:14 AM

Yes, I agree with you. It can be achieved with routing option config using qualified next hop for tunnel routes.

 

Let me know if you are facing any issues with that.

 

 

-Sarab

Highlighted
SRX Services Gateway

Re: VPN Redundancy with dual ISP

‎12-22-2013 11:56 PM

Yes it can be done by static routing with a qualified-next-hop with a higher pref towards the "backup" tunnel. I would suggest to use a dynamic routing protocol like OSPF or BGP within the vpn's

Marc



-----------------------------------------------------------------
Please Mark My Solution Accepted if it Helped, Kudos are Appreciated Too
-----------------------------------------------------------------
Highlighted
SRX Services Gateway

Re: VPN Redundancy with dual ISP

‎12-28-2013 02:19 PM

Hi Marc,

 

Many thanks. I have no experience with OSPF, how would I go about configuring OSPF over vpn in my scenario i.e.:

 

Site 1 (Dual ISP with 2 VPN Tunnels to different sites, site 1 and site 2, for different services)

SRX110

 

Site 2 & Site 3 - Single ISP in both sites, using Juniper ns-50

 

 

many thanks.

Highlighted
SRX Services Gateway

Re: VPN Redundancy with dual ISP

‎10-22-2014 05:18 AM

I have been struggling with a similar setup up between a SRX110 with Dual ISP and a Fortinet Single peer IP. Have tried the routing options method and it works fine for the primary ISP1, when ISP1 fails it does fail over to ISP2 but the tunnel is very unstable and flaps, slod routing table does not always update to use st0.2 upon failure. I beleive this may be due to the 2nd tunnel not being fully up at the time. Sometimes will not come up at all unless the  ipsec-key-management is restarted. I believe it mostly is an issue with the Phase 2. I also have RPM running with probes and that seems to be working fine when Isp1 goes down. Here is my config

 

interfaces {
fe-0/0/0 {
unit 0 {
family inet {
address 207.122.152.148/27;

fe-0/0/6 {
unit 0 {
description Rogers;
family inet {
address 216.122.226.68/29;

 

vlan {
unit 1 {
family inet {
address 10.1.2.122/24;

 

routing-options {
static {
route 10.3.40.0/24 next-hop 10.1.2.1;
route 10.1.60.0/24 next-hop 10.1.2.1;
route 0.0.0.0/0 {
next-hop 207.122.152.129;
qualified-next-hop 216.122.226.65 {
preference 10;
}
preference 5;
}
route 10.1.1.0/30 {
next-hop st0.1;
qualified-next-hop st0.2 {
preference 10;
}
preference 5;
}

 

gateway gw_Fortinet {
ike-policy ike_pol_Isp1;
address 129.9.66.56;
dead-peer-detection;
external-interface fe-0/0/0.0;
}
gateway gw_FortinetIsp2 {
ike-policy ike_pol_ISP2;
address 129.9.66.56;
dead-peer-detection;
external-interface fe-0/0/6.0;

 

vpn1 {
bind-interface st0.1;
ike {
gateway gw_isp1;
ipsec-policy ipsec_pol_ISP1;
}
traffic-selector Host1 {
local-ip 1.1.1.1/32;
remote-ip 10.1.1.1/32;
}
traffic-selector Host2 {
local-ip 1.1.1.1/32;
remote-ip 10.1.1.2/32;
}
traffic-selector Host3 {
local-ip 1.1.1.1/32;
remote-ip 10.1.1.3/32
}
establish-tunnels immediately;
}
vpn Isp2 {
bind-interface st0.2;
ike {
gateway gw_Isp2;
ipsec-policy ipsec_pol_Isp2;
}
traffic-selector Host1 {
local-ip 1.1.1.1/32;
remote-ip 10.1.1.1/32
}
traffic-selector Host2 {
local-ip 1.1.1.1/32;
remote-ip 10.1.1.2/32;
}
traffic-selector Host3 {
local-ip 1.1.1.1/32;
remote-ip 10.1.1.3/32
}
establish-tunnels immediately;

 

interfaces {
fe-0/0/0.0 {
host-inbound-traffic {
system-services {
ping;
https;
}
}
}
st0.1;
fe-0/0/6.0 {
host-inbound-traffic {
system-services {
ping;
}
}
}
st0.2;
}
}
}
}

Feedback