
OPERATIONAL DEFECT DATABASE
...


...

ESP traffic forwarding issue when there are two routes present on cedge towards remote IPSEC peer.
ESP packets to peer are send out the wrong WAN interface 2, while source interface is WAN 1 and IKE packets are correctly send from 1 interface. So we saw encrypted (sent) ESP counters increasing but there were zero decrypted (received) traffic from Destination. Once we disabled ECMP route on cedge, this fixed issue and IPSEC tunnel become operational.
Should use a Local Policy to redirect IPSec/IKE control packets to the interface in "route via <interface" of the Tunnel. Step 1. Identify the physical interface associated with the Tunnel in the config "tunnel route-via GigabitEthernet0/0/0 mandatory" Step 2. For the Tunnel Destination IP "tunnel destination 165.225.80.37" Obtain the next hop ip for the interface it has to egress out. Step 3. Define a access-list and a route map something like shown below: #sh ip access-lists Extended IP access list SIG-1 100 permit ip host any (93 matches) Extended IP access list SIG-2 100 permit ip host any (77 matches) Set the action of these rules as "set ip next-hop " in the route map. You could also fine tune the access list by adding the port numbers 4500 and 500. #sh route-map route-map SIG-RM, permit, sequence 10 Match clauses: ip address (access-lists): SIG-1 Set clauses: ip next-hop 192.168.200.1 Policy routing matches: 179 packets, 22609 bytes route-map SIG-RM, permit, sequence 35 Match clauses: ip address (access-lists): SIG-2 Set clauses: ip next-hop 192.168.0.1 Policy routing matches: 154 packets, 20548 bytes
Click on a version to see all relevant bugs
Cisco Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.