Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
1311
Views
5
Helpful
4
Replies

Four 43xx routers VPN FULL redundancy?

rsmith
Level 3
Level 3

‎10-05-2017 04:28 PM - edited ‎03-12-2019 04:36 AM

I have seen configuration examples for a single router VPN redundancy to a pair of routers, but what if you have a pair of routers at each end? I am hoping to achieve full VPN failover redundancy for any device failure.

Is it as simple as adding the "default" and secondary peers on all 4 routers?

(IE,with Routers 1 and 2 at core end, Routers 3 and 4 at Remote end):

1 to 3 default, 1 to 4 secondary. 3 to 1 default, 3 to 2 secondary

2 to 4 default, 2 to 3 secondary. 4 to 2 default, 4 to 1 secondary

 

Also, If implementing VRRP/HSRP(on BOTH ends), does this all go out the window, and how would full redundancy be achieved in this scenario?

To further muddle this question, the Core side Routers have VRF configuration and two separate OSPF processes set to area 0 (per VRF).

Labels:
0 Helpful
4 Replies 4

Philip D'Ath
VIP Alumni
VIP Alumni

‎10-05-2017 06:42 PM

If the outside of each router is in the same subnet then it is easier to configure hsrp, and configure the peers to use that. Then you have a nice simple configuration with a single VPN that is fully fault tolerant.

Make sure you create an isakmp profile and use local-address to reference the hsrp address on the local router.

crypto isakmp profile isakmp-site
keyring ...
match identity address ...
local-address <hsrp address>

rsmith
Level 3
Level 3
In response to Philip D'Ath

‎10-06-2017 02:03 PM

Thank you!.. I did not know about the profile and local address piece. Below is my conceptual configurations, I know there is extraneous (probably conflicting) configuration information, and very likely some missing pieces still. I am hoping for some peer review and feedback before it gets tested, as one end is  "semi-production", do not want to disrupt services:

 

(RTR1).1 -                  - .4(RTR3)
                \                 /
            (VIP).3----.6(VIP)
                /                 \
(RTR2).2 -                 - .5(RTR4)

 

RTR1:
crypto isakmp profile RTR1
vrf Outside
keyring Outside_ring
match identity address x.x.x.6 255.255.255.255
local-address x.x.x.3
crypto map aesmap 10 ipsec-isakmp
set peer x.x.x.6
set transform-set aesset
match address Encrypt
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
lifetime 28800
crypto ipsec transform-set aesset esp-aes esp-sha-hmac
mode tunnel

interface GigabitEthernet0/0/0
description Outside
vrf forwarding Outside
ip address x.x.x.1 255.255.255.0
standby 255 ip x.x.x.3
standby 255 priority 120
standby 255 authentication auth1
standby 255 track 1 decrement 15
crypto map aesmap

ip access-list extended Encrypt
permit ip a.a.a.0 0.0.0.255 b.b.b.0 0.0.0.255


RTR2:
crypto isakmp profile RTR2
vrf Outside
keyring Outside_ring
match identity address x.x.x.6 255.255.255.255
local-address x.x.x.3
crypto map aesmap 10 ipsec-isakmp
set peer x.x.x.6
set transform-set aesset
match address Encrypt
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
lifetime 28800
crypto ipsec transform-set aesset esp-aes esp-sha-hmac
mode tunnel

interface GigabitEthernet0/0/0
description Outside
vrf forwarding Outside
ip address x.x.x.2 255.255.255.0
standby 255 ip x.x.x.3
standby 255 priority 120
standby 255 authentication auth1
standby 255 track 1 decrement 15
crypto map aesmap

ip access-list extended Encrypt
permit ip a.a.a.0 0.0.0.255 b.b.b.0 0.0.0.255

RTR3:
crypto isakmp profile RTR3
vrf Outside
keyring Outside_ring
match identity address x.x.x.3 255.255.255.255
local-address x.x.x.6
crypto map aesmap 10 ipsec-isakmp
set peer x.x.x.3
set transform-set aesset
match address Encrypt
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
lifetime 28800
crypto ipsec transform-set aesset esp-aes esp-sha-hmac
mode tunnel

interface GigabitEthernet0/0/0
description Outside
vrf forwarding Outside
ip address x.x.x.4 255.255.255.0
standby 255 ip x.x.x.6
standby 255 priority 110
standby 255 authentication auth1
standby 255 track 1 decrement 15
crypto map aesmap

ip access-list extended Encrypt
permit ip b.b.b.0 0.0.0.255 a.a.a.0 0.0.0.255


RTR4:
crypto isakmp profile RTR2
vrf Outside
keyring Outside_ring
match identity address x.x.x.3 255.255.255.255
local-address x.x.x.6
crypto map aesmap 10 ipsec-isakmp
set peer x.x.x.3
set transform-set aesset
match address Encrypt
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
lifetime 28800
crypto ipsec transform-set aesset esp-aes esp-sha-hmac
mode tunnel

interface GigabitEthernet0/0/0
description Outside
vrf forwarding Outside
ip address x.x.x.5 255.255.255.0
standby 255 ip x.x.x.6
standby 255 priority 110
standby 255 authentication auth1
standby 255 track 1 decrement 15
crypto map aesmap

ip access-list extended Encrypt
permit ip b.b.b.0 0.0.0.255 a.a.a.0 0.0.0.255

0 Helpful

Philip D'Ath
VIP Alumni
VIP Alumni
In response to rsmith

‎10-06-2017 03:34 PM

I think that should work.  Have you considered using the easier VTI tunnel approach?

 

https://www.cisco.com/en/US/technologies/tk583/tk372/technologies_white_paper0900aecd8029d629.html

0 Helpful

rsmith
Level 3
Level 3
In response to Philip D'Ath

‎01-04-2018 09:41 AM

I have the 4 Routers set up with HSRP, and VPN on the Virtual IP, but it does NOT transfer the VPN state when the routers fail over. Below the question is the (cleaned) configuration I currently have:

 

1: Per this document below, one caveat states "Stateful Failover for IPsec is not supported on platforms running Cisco IOS-XE software."

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_vpnav/configuration/15-mt/sec-vpn-availability-15-mt-book/sec-state-fail-ipsec.html

2: Per this document (OLD, 2012), states "VPN Availability Configuration Guide, Cisco IOS XE Release 3S"

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_vpnav/configuration/xe-3s/sec-vpn-availability-xe-3s-book/sec-vpn-ha-enhance.html

3: and a 3rd document (2005, not linked) states to use "ssp", which is not an option on these 43xx routers...

So, what am I missing for full Stateful failover for the VPN crypto tunnels?... (peer IP address for the G0/0/1 is x.x.255.69)

 

4331-Test#
crypto keyring clets_ring
pre-shared-key address x.x.255.65 key (key)
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
lifetime 28800
crypto isakmp profile clets
keyring clets_ring
match identity address x.x.255.65 255.255.255.255
local-address x.x.255.70
crypto ipsec transform-set aesset esp-aes esp-sha-hmac
mode tunnel
crypto map aesmap 10 ipsec-isakmp
set peer x.x.255.65
set transform-set aesset
set isakmp-profile clets
match address acl_VPN
ip access-list extended acl_VPN
permit ip x.x.101.0 0.0.0.255 x.x.30.0 0.0.0.255
permit ip x.x.101.0 0.0.0.255 x.x.167.0 0.0.0.255
permit ip x.x.101.0 0.0.0.255 x.x.34.0 0.0.0.255
permit ip x.x.101.0 0.0.0.255 x.x.212.0 0.0.0.255

4331-Test#
interface GigabitEthernet0/0/1
description RemoteRedundant
ip address x.x.255.68 255.255.255.224
no ip redirects
no ip unreachables
no ip proxy-arp
ip pim sparse-dense-mode
standby 200 ip x.x.255.70
standby 200 priority 90
standby 200 preempt
standby 200 authentication Test
standby 200 name VPNTEST
negotiation auto
crypto map aesmap redundancy VPNTEST

 

The OTHER end also utilizes VRF's, but I don't think that configuration is relevant to the issue I am having...

Russ

 

0 Helpful
Customers Also Viewed These Support Documents