Routing
Highlighted
Routing

DR over IPSEC VPN

‎11-08-2019 11:07 AM

Hello,

 

I am trying to see how to stand up a DR site.

 

Current topology:

Remote site (SRX345 HA) - OSPF via st0 interface with 2 physical external 1G ISP connections with rpm probing and ip-monitoring for failover 

Datacenter site  (SRX1500 HA) - OSPF via st0 interface with 2 physical external 1G ISP connections with rpm probing and ip-monitoring for failover. The IPSEC topology is hub and spoke.  

 

Future Datacenter will be: 

Edge 1 (srx1500 no HA) - 1G connection to ISPA

Edge 2 (srx4200) - 10G connection to ISPB

Edge 2 (srx4200) - Additional 10G connection to disaster recovery (secondary datacenter) with the same equipment for replication.

 

Remote sites need to have local ISP failover to support the tunnel locally as well tunnel connections to the primary and secondary datacenter. 

 

Questions:

1. How can you configure OSPF so that there is no asymmetric routing?

 

2. How can you configure IPSEC tunnels so that the remote sites can failover between primary and secondary datacenter?

 

Any assistance would be greatly appreciated.  

 

Sincerely, 

 

Under Pressure

5 REPLIES 5
Highlighted
Routing

Re: DR over IPSEC VPN

‎11-09-2019 04:27 AM
1. How can you configure OSPF so that there is no asymmetric routing?

2. How can you configure IPSEC tunnels so that the remote sites can failover between primary and secondary datacenter?

Create separate vpn tunnels on each ISP with separate st0 interfaces to all the sites.

For example, 2 ISP at backup site gets two tunnels to the single ISP at the other sites.

 

The direct link from the primary data center would come in on another interface.

 

Setup your OSPF on all of the links and use the link cost metric in OSPF to have the routes prioritized in the order you want the links to be used.  

 

As each option fails the ospf routing table will automatically shift the traffic in the desired order on both sides keeping the traffic symetrical.

 

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Highlighted
Routing

Re: DR over IPSEC VPN

‎11-18-2019 06:21 PM

Steve,

 

Thank you for the reply.  I am going to try to lab up the scenario you mentioned.  

 

Does that mean that each remote site will have 2 st0 interfaces binded in the ipsec ike-vpn, each mapped to 2 ike gateways (2 referencing each physical interface), with st0 interfaces running ospf and a metric applied to the backup path? 

 

Example (remote side):

set interfaces st0 unit 0 family inet address 10.0.0.1/24

set interfaces st0 unit 1 family inet address 10.1.0.1/24

set security ike gateway gw-siteC ike-policy ike-phase1-policy
set security ike gateway gw-siteC address 3.3.3.2 (DC 1)
set security ike gateway gw-siteC external-interface ge-0/0/0.0

set security ike gateway gw-siteC ike-policy ike-phase1-policy
set security ike gateway gw-siteC address 3.3.3.2 (DC 1)
set security ike gateway gw-siteC external-interface ge-0/0/1.0

set security ike gateway gw2-siteC ike-policy ike-phase1-policy
set security ike gateway gw2-siteC address 4.4.4.2 (DC 2)
set security ike gateway gw2-siteC external-interface ge-0/0/0.0

set security ike gateway gw2-siteC ike-policy ike-phase1-policy
set security ike gateway gw2-siteC address 4.4.4.2 (DC 2)
set security ike gateway gw2-siteC external-interface ge-0/0/1.0

set security ipsec vpn vpn-siteC bind-interface st0.0 (DC 1 VPN)
set security ipsec vpn vpn-siteC ike gateway gw-siteC
set security ipsec vpn vpn-siteC ike ipsec-policy ipsec-phase2-policy

set security ipsec vpn vpn2-siteC bind-interface st0.1 (DC 2 VPN)
set security ipsec vpn vpn2-siteC ike gateway gw2-siteC
set security ipsec vpn vpn2-siteC ike ipsec-policy ipsec-phase2-policy

 

The IP monitoring and the rpm probing will cause the next hop for the ISP to be injected into the routing table when the probe fails, but how can you configure ospf to prefer one tunnel over the other?

 

Would the primary/secondary datacenters and the remote sites have OSPF enabled on the tunnel interfaces with IPs in the same subnet?  

 

Thank you so much for replying.

 

Bryan

 

 

Highlighted
Routing

Re: DR over IPSEC VPN

‎11-20-2019 02:42 AM

Yes, there are two vpn tunnels, one on each ISP and they can be active all the time just using the ospf cost to prefer the primary tunnel.  Whenever the primary isp fails there is no need for vpn monitor because the tunnel will simply fail and traffic transition over to the backup path in ospf.

 

The tunnel interfaces are treated as a routed link from DC site to remote site.  So these can be /31 or /30 address pairs.  The ports are added to the same ospf area on each site.  And you simply increase the ospf link cost on the backup tunnel.

 

Because routing is via ospf no static route failover is needed the routing change is natural to the protocol.

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Highlighted
Routing

Re: DR over IPSEC VPN

‎01-01-2020 05:54 PM

Steve,

 

Thank you for all of your help.  It took a while, but I have configured the networks in a hub/spoke fashion with 2  st0 interfaces  to account for 2 ISPs at the spoke sites.  The hub site only has 1 ISP at the moment.  The OSPF neighborship has come back up and the metric determines the primary path.  I am using RPM to trigger the preferred route if the primary ISP goes down at the spoke site.  The issue that I am having exists in the IP spoofing messages that are received in the chassis cluster on the edge.  ISP 1 is plugged into node0 and ISP is plugged into node1.  If ISP1 fails, I get the following logs:

 

RT_IDS: RT_SCREEN_IP: IP spoofing! source: X.X.X.X, destination: ISP.ISP.ISP.ISP , protocol-id: 1, zone name: untrust, interface name: ge-0/0/0.0, action: drop  

All traffic is intermittent, and both ISP default routes remain in the routing table.  The only thing that fixes this is disabling one of the ISP interfaces. There is IP spoofing configured under the screen for the ISP security zone interfaces.  Do you know what could be causing this?  Could it be the screen or the arp/forwarding table entries that cause issues as the secondary route becomes active? This setup works perfectly fine with a single chassis.   Any assistance is greatly appreciated.  

 

Respectfully,

BK

Highlighted
Routing

Re: DR over IPSEC VPN

‎01-02-2020 02:51 AM

I see two things to check out.

 

How do you have the cluster configured since you have the ISP directly connected to both nodes.  A standard active/passive design does not work for this as you have to have both ISP working and the secondary node would be passive.

 

Why is the default route for the failed ISP still active?  This could cause routing issues that might play into the packet loss you are seeing.

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Feedback