cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1651
Views
7
Helpful
19
Replies

ECMP and PBR with dual FTD 2140s managed by FMCv on 7.2.5.1

emasters
Level 1
Level 1

For some context, we have dual Firepower 2140s in HA managed by FMCv. Both FTD and FMCv are on 7.2.5.1 as of last week at the start of 2024. 

We currently utilize our FTDs as external firewalls and head-ends for both site-to-site VPNs and Remote Access VPNs. Our RA VPN users are currently utilizing IPsec. We have dual 1Gbps internet connections on a load-balancer that sits in front of the FTDs while the FTDs themselves have just a single outside connection that feeds into the LAN of the load-balancer. We also have a new 10Gbps connection as of the last month that we'd like to start utilizing. The cost of using 10Gbps on our load-balancer is going to be costly as it's about $70k worth in licensing. This started the research of seeing if the FTDs were capable of load-balancihng outbound traffic and that's where I came across ECMP and Policy Based Routing. As of 7.2, the FMC natively supports the configuration of both without the need of FlexConfig. Neat. 

Naturally, I started reading documentation on the requirements. For the most part, I met all the requirements execpt for two as noted by the documentation here.

  • Following interfaces cannot be associated with an ECMP zone -> Interfaces in RA VPN configuration with SSL enabled
  • Threat defense does not support ECMP with NAT in IPsec sessions—a standard IPsec virtual private network (VPN) tunnel does not work with NAT points in the delivery path of IPsec packets.

My first question/concern with the first point is are they referring to having SSL on the interface itself, or having SSL enabled in the RA VPN Group Policy? In other words, SSL enabled within the Access Interface configuration

emasters_0-1704987578166.png

Or.....the Group Policy

emasters_1-1704987621797.png

If it's referring to having SSL enabled on the actual interface itself and need to turn that off, then I suppose I'll need to come up with a gameplan regarding our VPN users as, If I recall, all RA VPN sessions utilize SSL initially. 

The second point I may just need clarification on it in general so I'm not misunderstanding the underlying concept.

The end goal here would be to have both ISPs terminating on the FTD with the ability to load-balance outbound internet traffic utilizing ECMP and PBR to avoid paying the licensing for the load-balancers. However, it seems that the VPNs may be my stopping point if I do not have an alternative solution.

I do have an active case with TAC opened about this, but figured I'd ask the question to the community and see if anyone has ever utilized ECMP/PBR with the FTD and some feedback. 

Thank you for your time. 

19 Replies 19

Also, I would assume that if I have two public A records for both ISP interfaces, and the user resolves to just one, then I'd imagine the users VPN traffic would traverse that interface and that interface only for inbound/outbound. Load-balancing in this case wouldn't be a necessity per say, but it would be nice to have redundancy should ISP1 fail.

Correct. Inbound VPN traffic will create connection on, say, outside2 interface of the firewall and reverse traffic will always take the same interface outside2. But if outside2 fails (doesn't matter if interface itself fails or connectivity is lost), AnyConnect will go into the "reconnecting" state until the user disconnects manually.

but I also realized that you could use applications for your rules, but not DNS

No, not really. An "application" in this context is a "DNS domain name" or "domain + subnet/protocol/port" combination. This is also called network-service group or NSG. This article explains the concept very well: https://secure.cisco.com/secure-firewall/docs/policy-based-routing-with-path-monitoring. So, this can be used to route certain "domain" traffic forcefully to specific outside interface.

It appears to me that at the current level of FTD software development it would be easier to use something like

route outside1 0.0.0.0 128.0.0.0 x.x.x.x
route outside2 128.0.0.0 128.0.0.0 y.y.y.y

avoiding all complications with ECMP, NAT, PBR, etc.

 

 

 

emasters
Level 1
Level 1

Quick update regarding my case with TAC:

"Hi team,
Regarding you questions, when configuring the RAVPN you can select the protocols that you are going to use for the tunnel and the interface under the tab "Advanced interfaces". On that tab we should disable the ssl protocol and only enable the ipsec protocol so you can use ECMP on the same interface where the VPN is being formed. Another change we need to perform to use ipsec is select the ipsec protocol on the xml profile as is shown on the screenshot."

The screenshot TAC attached. This is something I already have set for my users. 

07_02_59.jpg

Which would mean this would involve disabling SSL at the interface level under Access Interfaces, which is what I was afraid of.

I think at this point I'm thinking this is a lost cause without this being a completely horrible experience for our end users. 

 

  

I confuse here 
you allow IKEv2 and SSL(+DTLS) in outside but that not meaning you use IKEv2 anyconnect. 
if you decide to go with ECMP then SSL completely not work if you permit or not in outside. 
and sure client will not happy using ikev2 instead of ssl 
MHM

emasters
Level 1
Level 1

So, had my chat with some folks from Cisco that specialize in security. Disabling SSL for Remote Access VPN would seem to do more harm than good. It would ruin the experience and it was advised not to move forward with ECMP/PBR. However, we tossed around the idea of having a pair of firewalls that were dedicated for VPN and VPN only. This would include both Site to Site and Remote Access and would eliminate a few of the caveats regarding ECMP/PBR and would allow us to move forward. This should be able to hold us over until we're in a position to setup BGP. 

I can follow up once we've moved forward and leave some feedback. That's where things stand at the moment.

Ok @emasters , this is a move in the right direction.

As a side note, I've just accidentally found an answer to your second question about documentation saying "Threat defense does not support ECMP with NAT in IPsec sessions — a standard IPsec virtual private network (VPN) tunnel does not work with NAT points in the delivery path of IPsec packets". This is yet another software caveat:

 
CSCwf43850 ECMP + NAT for ipsec sessions support request for Firepower
Symptom: Incoming IPSEC packets dropped with Drop-reason: (bad-ipsec-prot) IPSEC not AH or ESP. Conditions: Equal-Cost Multi-Path (ECMP) over VPN and NAT Traversal (NAT-T, ESP UDP encapsulation). Workaround: Do not use NAT-T by avoiding NAT in the path. If not possible to avoid NAT-T do not use ECMP. Further Problem Description: This is a day one issue - the features combination never worked.
 
This bug was fixed in 9.18.4.8 and 9.20.2.
 
 
Review Cisco Networking for a $25 gift card