09-12-2017 02:23 PM - edited 03-12-2019 04:32 AM
Dear all,
I hope you're doing fine.
I have a problem with an IPSEC tunnel between ASA and IOS.
ASA is running 9.6.2
IOS router - 2911 - is running 155-3.M4a
In attachment the design in place. But let me exlpain it in details.
ISP1 - Optical Fiber: public range: 1.1.1.0/24
ISP2 - Satellite: public range: 2.2.2.0/24
I have a Cisco ASA 5545 located in our HQ, which runs as VPN Hub concentrator within a DMZ. Public IP is 1.2.3.4/32
My remote router (2911) is connected to ISP2 router and the IP address is 2.2.2.254
ISP2 router is connected to his SATCOM and to ISP1 (ISP1 provide Internet over Fiber). This router makes the routing decision.
In a normal state, when both access are up and running, the prefered path is via Fiber (via ISP1).
So the ISP2 (who manage the ISP2 router) forward the traffic via Fiber (ISP1) and nat it behinf an IP within ISP1 subnet. It uses IP SLA + Track to insert a default route via ISP1.
If fiber goes down, default route disapears and a floating default route via SATCOM is inserted into the routing table. In this case ISP2 do not perfom nat, and forward the traffic directly.
Please be aware that this design is not belongs to me. It's ISP2 decision.
Over this active/standby internet access, I have establised an IPSEC L2L tunnel.
As potentially the IP address of the remote peer can change during a failure of the Fiber link, I built the VPN based on IKEv1 certificate authentication.
From ASA point of view, the name of the connection profile, is based on the CN presents into the certificate.
In a normal state (when all trafic is routed via ISP1) the L2L tunnel is established without problem.
In case of failure of ISP1, all traffic is forwarded via SATCOM (ISP2). As the routing decision is performed by ISP2 router,
my remote peer doesn't notice a change on the routing and continues to send traffic.
From From ASA perspective, the source of the ESP packets as changed. Before the failure, the source of the tunnel was 1.1.1.100. And during the outage it becomes 2.2.2.254. (cf attached diagram).
At this time everthing works fine.
I know that IPSEC SA are Unidirectional, and based on certificate authentication the ASA do not drop the traffic when the source of the packet change. I think this is a normal behavior.
Please confirm my assumption.
Next, in case of fiber recovered, the traffic from remote site is forwraded via ISP1. So the source of the packet change again.
But in this specific case, the ASA receive ESP packets from the original IP (1.1.1.100) but continues to send back packets to the (2.2.2.254).
So I have asymetric traffic. One way over SATCOM and I way over Fiber.
I tried to modify the idle timeout of the group policy on the ASA, but without success.
To fix that problem, the only workaround I found is to clear the tunnel in the ASA.
Can someone help me?
Thank you very much.
Regards,
Isidore
09-14-2017 10:14 AM - edited 09-14-2017 10:23 AM
Dead Peer Detection (DPD) is a method that allows detection of unreachable peer.
DPD negotiation procedure and two new ISAKMP NOTIFY messages. Specifically, DPD is negotiated via an exchange of the DPD ISAKMP Vendor ID payload, which is sent in the ISAKMP MM messages 3 and 4 or ISAKMP AM messages 1 and 2. DPD Requests are sent as ISAKMP R-U-THERE messages and DPD Responses are sent as ISAKMP R-U-THERE-ACK messages.
Router(config)#crypto isakmp keepalive 10 periodic
After that clear all SA
Here I conf VPN IPSEC L2L between 101.1.1.10 and 102.1.1.10 both are routers
For more details
https://supportforums.cisco.com/t5/security-documents/dead-peer-detection/ta-p/3111324
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide