Block access to Remote Access VPN by IP Address

[PerryGuy621]

I am running a couple of Cisco FTD 2110 managed with FMC and am looking for the best way to block access to our remote access VPN by IP. From doing some reading it looks like the best (and only?) way to do this is via a control plane ACL deployed via Flex Config. I saw another post that showed how this could be accomplished via geo but I am unsure on that syntax. I'm hoping someone could provide what syntax is used or point me towards some documentation for this?

Thank you!

[Lee Dress]

I understand this is an old thread, but I'm looking to deploy this on my system as I've been getting hit by some vpn attempts from bad locations. My question is this:  I have 2 outside interfaces that serve VPN access. Can I do the same to both interfaces in one object like this: 

[Marvin Rhoads]

That should work. But if you're on a shared list used by bad actors, the attempts will continue to come from varied addresses without end. Most people just let the firewall silently drop them.

[Lee Dress]

thanks for the quick response.  I'll give it a try. 

i seem to have 2 subnets that keep trying.  we use DUO on our VPN so they're not getting anywhere.  but I'd prefer to get them to stop knocking on the door completely. 

[Lee Dress]

one last question.  how do I negate it if all goes bad? 

do I simply put a "no" in front of the line (access-group $controlplaneacl in interface nitel control-plane) and redeploy? 

[Marius Gunnerud]

do I simply put a "no" in front of the line (access-group $controlplaneacl in interface nitel control-plane) and redeploy? 

That is correct.

[Lee Dress]

thank you.   this stopped the hits I was getting immediately. 

[Lee Dress]

I can confirm that this works on 2 interfaces. 

I installed it on one, and then started getting hits on the second interface.  once I added the second interface and deployed all attempts from the blocked IPs failed. 

[Lee Dress]

this works great for me.  I created a group called IP_Blocklist in FMC and referenced that in the flexconfig.  anytime I get a new Brute force attempt on my VPN, I add the IP (or subnet) as an object, then add the object to the group and deploy to the device. 

[jmeetze]

Being a long time Cisco admin, this is a bad design on Cisco's part.  Trying to block malicious/unwanted traffic by IP is a management nightmare.  You're basically just playing whack-a-mole.  Having a NGFW in this day and age should allow you to apply the same security intelligence to all of your traffic to protect your network.  Especially with how many vulnerabilities affect RAVPN.  Granted, two-factor helps mitigate this, but being able to use a simple Geo Block list on your VPN interface should be simple to accomplish.

[John Hinckley]

I am also in agreement with this assessment.  How is it that a Cisco firewall, in the year 2024, can't use threat intelligence to look at a source IP and geo-block the packet BEFORE passing it off to the RA Handler?  And IMO, having to use MFA to block an RA attempt pretty much defies the concept of a firewall.  Blocking a malicious packet at the earliest layer is not only the best option but it allows for additional controls at upper layers should a crafty packet get through.  

[Marvin Rhoads]

Providing this feedback to your Cisco or partner account manager is the best way to get it prioritized with the product development team.

If you attend Cisco Live, be sure to track down the folks manning the Cisco Security booths, design clinics, breakout sessions etc. and let them know in person.

[John Hinckley]

If only I had read this sooner, I just wrapped up the DevSec Test Drive in Miami yesterday.   Thanks for the advice, Marvin. 

[scottyd]

I also agree. Also in line with this problem is the fact that traffic destined to the actual interface IP of the FTD is not logged. Do a filter with connection events and you will find out. Appalling, for a security device.

[Lee Dress]

I 100% agree with this assessment.   And I do have to play whack a mole.  every day I'm looking at VPN attempts and failues, doing an IP Lookup and then adding an IP (or large subnets) to my ip blacklist.  The fact that there is so much security intelligence (like the Cisco-Intelligence-feed that is updated regularly)  that can be applied to the passing traffic. We should be able to leverage a database or feed at the control plane level.  I've actually considered installing an edge router that has that type of functionality, but then why do I need a NGFW?? 

[tvotna]

Blocking to-the-box connections by geo IP (CSCvs65322) is not enough. FTD and ASA should also support:

- "set connection per-client-max" and "set connection per-client-embryonic-max" in MPF for to-the-box connections
- connection rate-limiting in MPF for both to-the-box and through-the-box connections
- connection rate-limiting for to-the-box connections in ASA resource manager in multiple mode ("limit-resource" system CLI)
- user-configurable TLS/JA3 filtering for to-the-box TCP/443 traffic
- pre-defined TLS/JA3 filters for AnyConnect on all supported operating systems
- multicore support for VPN control-plane on high-end platforms
- adaptive call admission control for IKEv2 and TLS which takes box load into consideration rather than just the number of tunnels under negotiation (TLS currently doesn't have any call admission control)
- much more efficient IKEv2 control plane which doesn't fail under stress
- diagnostic capabilities

Until then ASA/FTD configured as RA VPN hub should always be protected by some other specialized perimeter device capable of session rate-limiting and TLS/JA3 filtering.