01-11-2024 07:46 AM
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.
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
Or.....the Group Policy
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.
01-15-2024 12:12 PM
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.
01-16-2024 07:10 AM
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.
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.
01-16-2024 08:03 AM
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
01-23-2024 01:08 PM
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.
02-12-2024 09:01 AM
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:
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