I'm having issues to get the following trial setup to work. In essence the problem appears to be due to the routing in play here, but i would appreciate any insights into what am I doing wrong here.
(note: for reasons too long to explain I need the configuration to be based on classic crypto-maps + multiple peers, rather than VTIs and/or with HSRP):
R1, R2, and R3 are all connected onto the same LAN and IP subnet: 192.168.10.0/24
R1 and R3 are in effect a redundant IPSec tunnel mode Hub pair. R5 is an internet access gateway and R2 has a default route pointing to it.
I would like to set-up R2 to encrypt traffic to destinations in the hub, reachable via R1 (default) and R2 (backup). Let's say that these destinations are covered by 126.96.36.199/24.
My R2 config is:
interface GigabitEthernet2 ip address 192.168.10.2 255.255.255.0 negotiation auto crypto map hub1
crypto map hub1 20 ipsec-isakmp set peer 192.168.10.1 default set peer 192.168.10.3 set transform-set tset match address hub1
ip access-list extended hub1 permit ip 188.8.131.52 0.0.0.255 184.108.40.206 0.0.0.255
Now to get the traffic towards 220.127.116.11/24 to flow out of Gig2, I put a static route pointing at R1,
ip route 18.104.22.168 255.255.255.0 192.168.10.1
And this works nicely until R1 is simulated to fail (interface is shut).
After this event, I do see IPSec SA's timing out and a new SA established with 192.168.10.3 (R3). R3 even installs a reverse route for the network behind R2. Unfortunately however, I'm unable to get any traffic flowing.
R2#sh crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status 192.168.10.3 192.168.10.2 QM_IDLE 1005 ACTIVE
Debug crypto ipsec doesn't yield anything, so I suspect that the packets aren't even hitting the ipsec stage. The question is why? Is this type of directly connected IP sec peers not supported, or is this a bug? My assumption was that as long as the packet hit the right interface, the crypto-map would take care of things, and send the packet to R3. This does not appear to be happening though. Removing the static route to R1 and replacing it with one to R3 resolves matters, but that's not quite a solution (in the target deployment there cannot be a dynamic routing protocol between R2 and R1+R3.)
Here's a debug ip packet following ping from a local interface source.
R2#ping 22.214.171.124 source 126.96.36.199 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 188.8.131.52, timeout is 2 seconds: Packet sent with a source address of 184.108.40.206
Have you considered using ip sla that tracks the statis of R1's physical interface and configure two static routes on R2 with the route pointing to R3 having a higher metric? Then the route to R3 should be placed into the routing table once R1 fails.
Please remember to select a correct answer and rate helpful posts
Please remember to rate and select a correct answer
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...