Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

Cisco Employee

IPSec issue with directly connected peers

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.

 

 

Everyone's tags (1)
1 REPLY
VIP Green

Have you considered using ip

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
75
Views
0
Helpful
1
Replies