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!

[BlackSharpie]

Any updates from Cisco on a permanent fix for this issue?  Adding 10's of IP's daily to the CP ACL for countries we already Geo-Block is a pain.

[Marvin Rhoads]

The capability to natively geofence RA VPN connections is targeted for release 7.7 (tentatively early 2025).

It will not be in the next release (7.6, due in September 2024).

[scottyd]

Unbelievable. A basic function of a firewall. No wonder my colleges are switching to Checkpoint.

[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.