Hi,
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---R3
|------|
|
R2---R4
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 1.1.1.0/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 2.2.2.0 0.0.0.255 1.1.1.0 0.0.0.255
Now to get the traffic towards 1.1.1.0/24 to flow out of Gig2, I put a static route pointing at R1,
ip route 1.1.1.0 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 3.3.3.3 source 2.2.2.2 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
*Sep 8 14:23:31.338: FIBipv4-packet-proc: route packet from (local) src 2.2.2.2 dst 3.3.3.3
*Sep 8 14:23:31.338: FIBfwd-proc: Default:3.3.3.3/32 process level forwarding
*Sep 8 14:23:31.339: FIBfwd-proc: depth 0 first_idx 0 paths 2 long 0(0)
*Sep 8 14:23:31.339: FIBfwd-proc: try path 0 (of 2) v4-rcrsv-192.168.10.1 first short ext 0(-1)
*Sep 8 14:23:31.339: FIBfwd-proc: v4-rcrsv-192.168.10.1 valid
*Sep 8 14:23:31.339: FIBfwd-proc: ip_pak_table 0 ip_nh_table 0 if none nh 192.168.10.1 deag 0 chg_if 0 via fib 7F1D16FCC230 path type recursive
*Sep 8 14:23:31.339: FIBfwd-proc: depth 1 first_idx 0 paths 1 long 0(0)
*Sep 8 14:23:31.339: FIBfwd-proc: try path 0 (of 1) v4-adp-192.168.10.1-Gi2 first short ext 0(-1)
*Sep 8 14:23:31.339: FIBfwd-proc: v4-adp-192.168.10.1-Gi2 valid
*Sep 8 14:23:31.339: FIBfwd-proc: ip_pak_table 0 ip_nh_table 65535 if GigabitEthernet2 nh 192.168.10.1 deag 0 chg_if 0 via fib 0 path type adjacency prefix
*Sep 8 14:23:31.339: FIBfwd-proc: packet routed to GigabitEthernet2 192.168.10.1(0)
*Sep 8 14:23:31.339: FIBipv4-packet-proc: packet routing succeeded
*Sep 8 14:23:31.339: IP: tableid=0, s=2.2.2.2 (local), d=3.3.3.3 (GigabitEthernet2), routed via FIB
*Sep 8 14:23:31.339: FIBfwd-proc: ip_pak_table 0 ip_nh_table 65535 if GigabitEthernet2 nh 192.168.10.1 uhp 1 deag 0 ttlexp 0
*Sep 8 14:23:31.339: FIBfwd-proc: sending link IP ip_pak_table 0 ip_nh_table 65535 if GigabitEthernet2 nh 192.168.10.1 uhp 1 deag 0 chgif 0 ttlexp 0 rec 0
*Sep 8 14:23:31.339: IP: s=2.2.2.2 (local), d=3.3.3.3 (GigabitEthernet2), len 100, sending
*Sep 8 14:23:31.339: ICMP type=8, code=0
*Sep 8 14:23:31.339: IP: s=2.2.2.2 (local), d=3.3.3.3 (GigabitEthernet2), len 100, output feature
*Sep 8 14:23:31.339: ICMP type=8, code=0, feature skipped, IPSec output classification(35), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Sep 8 14:23:31.339: IP: s=2.2.2.2 (local), d=3.3.3.3 (GigabitEthernet2), len 100, output feature
*Sep 8 14:23:31.339: ICMP type=8, code=0, feature skipped, IPSec: to crypto engine(80), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Sep 8 14:23:31.339: IP: s=2.2.2.2 (local), d=3.3.3.3 (GigabitEthernet2), len 100, output feature
*Sep 8 14:23:31.339: ICMP type=8, code=0, feature skipped, Post-encryption output features(81), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Sep 8 14:23:31.339: IP: s=2.2.2.2 (local), d=3.3.3.3 (GigabitEthernet2), len 100, pre-encap feature
*Sep 8 14:23:31.339: ICMP type=8, code=0, feature skipped, IPSec Output Encap(1), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Sep 8 14:23:31.339: IP: s=2.2.2.2 (local), d=3.3.3.3 (GigabitEthernet2), len 100, pre-encap feature
*Sep 8 14:23:31.339: ICMP type=8, code=0, feature skipped, Crypto Engine(3), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE.
Success rate is 0 percent (0/1)
Welcome any suggestions.
