HSRP with GRE over ipsec problems

[new.abden]

I have the following scenario to connect my main HQ with other branches:

Two routers at the HQ and work in HSRP by thier internal Giga interface and use WAN connections by serial interfaces to create site to site VPN with other branches by using GRE over ipsec.

i need to know is this configuration right or there is another way to make it.

the following a sample of the configuration on both active and stand by routers and branch router

Active router

crypto isakmp key PASSWord address 172.18.x.x

crypto ipsec transform-set aes esp-aes esp-sha-hmac

crypto map secure 13 ipsec-isakmp
set peer 172.18.x.x
set transform-set aes
match address 101

interface Tunnel3
description branch01
ip address 10.100.30.1 255.255.255.0
keepalive 10 3
tunnel source 10.100.0.x
tunnel destination 172.18.x.x
crypto map secure

interface GigabitEthernet0/0
ip address 10.100.0.y 255.255.255.0
duplex auto
speed auto
standby 1 ip 10.100.0.x
standby 1 preempt

interface Serial0/0/0.16 point-to-point 
ip address 172.20.x.x 255.255.255.252

crypto map secure

access-list 101 permit gre host 10.100.0.x host 172.18.x.x

Standby router

crypto isakmp key PASSWord address 172.18.x.x

crypto ipsec transform-set aes esp-aes esp-sha-hmac

crypto map secure 13 ipsec-isakmp
set peer 172.18.x.x
set transform-set aes
match address 101

interface Tunnel3
description branch01
ip address 10.100.30.3 255.255.255.0
keepalive 10 3
tunnel source 10.100.0.x
tunnel destination 172.18.x.x
crypto map secure

interface GigabitEthernet0/0
ip address 10.100.0.z 255.255.255.0
duplex auto
speed auto
standby 1 ip 10.100.0.x
standby 1 preempt

interface Serial0/0/0.16 point-to-point

ip address 172.19.x.x 255.255.255.252

crypto map secure

access-list 101 permit gre host 10.100.0.x host 172.18.x.x

Branch router

crypto isakmp key PASSWord address 172.20.x.x
crypto isakmp key PASSWord address 172.19.x.x
crypto isakmp key PASSWord address 10.100.0.x

crypto ipsec transform-set aes esp-aes esp-sha-hmac

crypto map secure 13 ipsec-isakmp
set peer 172.19.x.x
set peer 172.20.x.x
set transform-set aes
match address 101

interface Tunnel3
description branch01
ip address 10.100.30.3 255.255.255.0
keepalive 10 3
tunnel source 172.18.x.x
tunnel destination 10.100.0.x
crypto map secure

interface Serial0/0/0.16 point-to-point
  ip address 172.18.x.x 255.255.255.252
crypto map secure

access-list 101 permit gre  host 172.18.x.x host 10.100.0.x

i got a lot of error massages with the active or the standby router and all the VPN parameters are correct from both HQ and branches routers

%CRYPTO-6-IKMP_MODE_FAILURE: Processing of Informational mode failed with peer at 172.18.x.x

[jan.nielsen]

Crypto map in your HQ need to use the standby keyword, to use the hsrp address, it won't work without it. Also i doubt it will work as the hsrp address is not on the interface you have put the crypto map on, so maybe try and put the crypto map secure on the lan interface instead of the serial intf.

Also do both hq routers have wan connections to all sites or are they split between them ??

Jan

[new.abden]

Thanks for your reply, and sorry but there was some missing part at the configuration that i posted

• i am currently applying the crypto map to the gre tunnel, serial interface and HSRP interface G0/0
• for the the WAN connection both HQ routers have wan connections for all the branch.
• i need to know where i need to add standby keyword.

[Todd Pula]

You may want to rethink your design a bit.  Based on the config you  provided, you are sourcing your GRE tunnels from the LAN facing  interface with a destination of the serial.  If the serial interface is  unavailable for any reason, the fact that you have HSRP configured on  the LAN is irrelevant.  The better approach in this case will be to  source the tunnel from the serial.  You will then apply the crypto map  to the serial interface only.  Configuring the crypto map on the tunnel  interface is no longer required and can lead to performance issues  related to MTU and SA selection.

[new.abden]

i need to clear some point:

• i am using the lan interface to create failover between the two router in case on the fail of the active HSRP , the standby will take the tunnels with the branches router.
• i didn't know about that i didn't need to apply the crypto map to the tunnel interface, so thank for that tip.
• i there any better design than what i am using now.
• this design is work but with errors as i said before.
  

thanks for your support

[Todd Pula · Accepted solution]

In your current design, I can see HSRP being used in order to provide HA  for the egress path towards the VPN edge.  From an IPSec HA standpoint,  HSRP is more commonly deployed when the WAN facing network is  Ethernet attached.  In this case, we can build the tunnel using the HSRP virtual  address giving a persistent IP.  The issue with your design is that in  order to reach the HSRP virtual IP, you need to traverse a single homed  serial interface. If this interface were to fail or if there was a problem in the routed path between the crypto peers, you will never be able to reach the HSRP virtual IP so the resulting solution will fail.

If this is the topology that we have to work with, then the only recommendations I can make is to incorporate IP SLA and tracking into your design.  For example, you could track the status of the primary router's serial interface.  If the interface fails, you could decrement the standby priority of the HSRP interface in order to force traffic to converge over the backup router path.  With ISAKMP keepalives configured on the hub and spoke routers, the routers should be able to recognize the failure and timeout the old SAs.  Because the spoke is configured with two peers, the router will be able to negotiae new SAs with the backup router.  When the serial interface comes back online, you can have the primary router preempt the standby status after a delay.  To detect indirect failures along the transit path, you could use ICMP IP SLA and tracking instead.  This design, however, would need to be properly tested to ensure stability during the failover process.