SRX Services Gateway
Reply
Regular Visitor
gasper
Posts: 9
Registered: ‎12-20-2010
0

srx vpn redundancy

Hello.

 

I have a question about dual ISP VPN redundancy. I have srx with two ISP connected. From each ISP there is VPN connectin to the remote location. ISP failover is working with watch-default-route script. In normal situation both VPN's are up and when I unplug the cable from primary provider, everything is working OK. But in the situation when script triggers failover both VPN's fail and the the second VPN reconnects. Why is that happening? I think that the second VPN via second ISP should stay up.

 

Anyone has an idea?

Super Contributor
srigelsford
Posts: 203
Registered: ‎04-14-2008
0

Re: srx vpn redundancy

It sounds like you are routing to the second VPNs peer gateway via the first ISP link...

Regular Visitor
gasper
Posts: 9
Registered: ‎12-20-2010
0

Re: srx vpn redundancy

I don't think it's a routing issue. Because, if I manually deactivate the primary route everything is working like it suppose to. Only when the script activates the failover, the I have a problem. I also started the ping from the secondary interface to it's default gateway, and when the scripts triggers, just stops to work.

 

When the script finishes, the everything starts to work.

Regular Visitor
gasper
Posts: 9
Registered: ‎12-20-2010
0

Re: srx vpn redundancy

Ok. I checked again, it seem that really is a routing issue. Looks like that ipsec sa's are established trough the primary link. I shold probably seperate the two ISP's in two different virtual routers to make this work. But I can't put ike gatewas into vr's bacause it's not supported. And what can I do now?

Recognized Expert
Dominik
Posts: 392
Registered: ‎01-05-2008
0

Re: srx vpn redundancy

[ Edited ]

Please be aware that even in JUNOS 10.4, the external-interface of a VPN must be in the default routing instance. Only the tunnel interface can be in a non-default routing instance (what is now officially supported with 10.4 but has still worked in older releases, for instance in 10.2 R3). The easiest solution is to install two /32 routes for the remote VPN endpoint, specifying their respective ISP router as next-hop. And of course verify that VPN2 specifies the external interface pointing to ISP2.

 

Regards,

Dominik

JNCIE et al.

--
The Axiom of Choice is obviously true, the well-ordering principle obviously false, and who can tell about Zorn's lemma?
Super Contributor
srigelsford
Posts: 203
Registered: ‎04-14-2008
0

Re: srx vpn redundancy

Why seperate into VRs?

You just need a static route to 'VPN2 peer Gateway' via the 'ISP2 Router'.

 

Using the following example:

ISP1: 1.1.1.0/24 gateway 1.1.1.254

ISP2: 2.2.2.0/24 gateway 2.2.2.254

 

VPN1 GW: 81.1.1.1

VPN2 GW: 81.2.2.2

 

route 81.1.1.1 via 1.1.1.254

route 81.2.2.2 via 2.2.2.254

 

Sam.

Regular Visitor
gasper
Posts: 9
Registered: ‎12-20-2010
0

Re: srx vpn redundancy

This doesn't solve the problem. I have on central location on srx two tunnel endpoints via two ISP's and on the remote location one tunnel endpoint. If I enter the host  route for tunnel endpoint via ISP2, then i have both IPSEC associations established over ISP2 link. Problem is because there is only one endpoint on the remote side.

 

What I would like to achieve is, that each vpn tunnel to the remote location is established over its own link.

Distinguished Expert
keithr
Posts: 979
Registered: ‎09-10-2009
0

Re: srx vpn redundancy

gasper, take a look at KB15545, it might be the ticket you're looking for to split your routing over your two ISPs with failover.

-kr


---
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated.
Regular Visitor
gasper
Posts: 9
Registered: ‎12-20-2010
0

Re: srx vpn redundancy

I allready checked that KB, but if I use this solution, there is problem, becouse IKE is not supported in custom VR.

Super Contributor
srigelsford
Posts: 203
Registered: ‎04-14-2008
0

Re: srx vpn redundancy

Ah, your problem makes sense now.

 

You could possibly use PBR (or filter-based-forwarding in Junos lingo I think). I guess you would need to terminate the tunnel on a loopback interface though to force the traffic through the filter in order to get routed correctly.

 

Sam.

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.