cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
353
Views
0
Helpful
7
Replies
Highlighted
Beginner

Cisco FTD FDM Dead Peer Detection

Good day, 

 

Has anyone done the flexconfig configurations for Dead Peer Detection (DPD) on a FTD 1120 in HA?

 

The design idea is to have multiple sites with different vendor equipment connect to the FTD via IPsec VPN.

 

There are 2 public IPs available to configure 2 separate VPN tunnels to each site.

 

We want automatic failover from the primary tunnel to the secondary tunnel in the event that connectivity is lost on the primary circuit. 

Additional Question:

1. If DPD is setup only on the FTD end will that be sufficient enough for detecting a failure of a VPN peer and doing the failover to the secondary link or would DPD need to be enabled on the other sites so that it can also know to use the secondary VPN.

2 ACCEPTED SOLUTIONS

Accepted Solutions
Highlighted
VIP Mentor

Hi @Davion Stewart 

DPD is enabled as default, from FTD 6.6 (FDM)

 

> show running-config all tunnel-group 12.1.1.1
tunnel-group 12.1.1.1 type ipsec-l2l
tunnel-group 12.1.1.1 general-attributes
default-group-policy |s2sGP|12.1.1.1
no tunnel-zone-id
tunnel-group 12.1.1.1 ipsec-attributes
no ikev1 pre-shared-key
peer-id-validate req
no chain
no ikev1 trust-point
isakmp keepalive threshold 10 retry 2
ikev2 remote-authentication pre-shared-key *****
ikev2 local-authentication pre-shared-key *****

 

When you say you have 2 public IP addresses available, are you referring to the FTD? You can only terminate a VPN to the IP address assigned to the FTD's physical interface.

 

HTH

View solution in original post

Highlighted
VIP Mentor

Yes. You would have to create 2 unique VPN topologies, specifying a different source interface on the FTD.

 

View solution in original post

7 REPLIES 7
Highlighted
VIP Mentor

Hi @Davion Stewart 

DPD is enabled as default, from FTD 6.6 (FDM)

 

> show running-config all tunnel-group 12.1.1.1
tunnel-group 12.1.1.1 type ipsec-l2l
tunnel-group 12.1.1.1 general-attributes
default-group-policy |s2sGP|12.1.1.1
no tunnel-zone-id
tunnel-group 12.1.1.1 ipsec-attributes
no ikev1 pre-shared-key
peer-id-validate req
no chain
no ikev1 trust-point
isakmp keepalive threshold 10 retry 2
ikev2 remote-authentication pre-shared-key *****
ikev2 local-authentication pre-shared-key *****

 

When you say you have 2 public IP addresses available, are you referring to the FTD? You can only terminate a VPN to the IP address assigned to the FTD's physical interface.

 

HTH

View solution in original post

Highlighted

Hi Rob, 

 

Thanks a million for your response. That's excellent news. 

 

Concerning the 2 Public IP addresses. 

 

We wanted to have redundancy for the VPN connections to the sites. Is there anyway to have a secondary peer configured?

 

I was inquiring about that but there was mention of only configuring a secondary peer via APIs? 

 

So for example, if connectivity is lost on the primary VPN circuit, then the FTD detects that the SA is down and tries to use the secondary link

Highlighted
VIP Mentor

Hi @Davion Stewart 

Not sure of your topology. Is the FTD at the main site which you want to be redundant? If so do you have 2 ISP circuits or 1? If you have 2 then you can use IP SLA to failover, it would be the remote peer devices that would need to support multiple peers.

 

Highlighted

That's correct, the FTD is at the main sites in HA. 

Its one ISP, but they provide 2 different Public IP ranges.

 

So then once the other sites support the ability to add multiple peers then then following will happen based on the scenario:

 

1. The first VPN connection becomes dead due to the primary public IP address becoming unreachable

2. The IP SLA detects that the IP is unreachable, the route will change to the secondary public IP address on the FTD. 

3. The remote side, seeing that the tunnel is down, tries the 2nd peer to establish connectivity.

4. Once DPD works, the first VPN SA will be torn down and when interesting traffic is seen, the secondary VPN tunnel should then be established.

I suppose once the remote peer can support multiple VPN peers then it should be able to work

 

 

Highlighted
VIP Mentor

Is the second IP address configured on a separate interface on the FTD? If not this won't work.

Highlighted

The second IP address is coming from on a separate port on the ISP's CPE. 

 

Just confirmed that current setup is that they have the ISP connections going to ISR routers respectively. 

The ISRs are doing HSRP for the LAN side that connects to the firewalls. So the firewalls are default routing to the VIP. 

 

I'm thinking to put the ISP connections directly onto the FTDs (The routers are only facilitating the public IP connections and having to do port forwarding of the VPN connections) so that there will now be two public outside interfaces on the FTD. 

 

This will allow us to configure the IP SLA to track the primary public interface and then in the event that fails, fail over to the secondary.

 

Then once the DPD kicks in and the other sites are configured with a secondary peer then it should form the secondary VPN. 

Question: the FTD will allow us to configure another VPN tunnel to the dame remote peer as long as we are using a different outside interface right?

Highlighted
VIP Mentor

Yes. You would have to create 2 unique VPN topologies, specifying a different source interface on the FTD.

 

View solution in original post

Content for Community-Ad