When VPN users are connected to HQ VPN, their visits to internet is actually from outside to outside.
For this to happen, we have this NAT rule:
nat (outside, outside) source dynamic RemoteUsers interface
Where “RemoteUsers” is actually the VPN IP address range.
To me, this sets the remote users really no limit to internet access when they are connected. I am not sure this is the best practice. I know I can limit the access to http and https to tighten the security further.
This rule used to be implemented in ASA, and now it is also on our FMC/FTD lab environment. So here is my question:
- Is there another way to do it?
- In case of FMC/FTD, can that outside to outside traffics be analyzed by IPS/IDS/URL/AMP?
I’m too far removed from hands on to tell you whether FTD can enforce security policy on hairpinned VPN traffic, but I can tell you avoiding inefficient backhauling of user Internet traffic while still applying security policy and enforcement is why SSE exists as a technology now.
Even if it is outside to outside it is still going thru the firewall. In fact the only way it works is because you have a rule allowing those VPN users to anything right now, or your default rule is set to allow. If you want to limit that, change the default rule to deny all and start making rules for your traffic.
If you have better internet controls on your network, you can bring the VPN traffic in to your network by overriding the ASA’s default route for VPN client traffic, eg:
route inside 0.0.0.0 0.0.0.0 <ip.of.next.hop> tunneled
In my organisation we split tunnel Teams traffic for Anyconnect clients with a dynamic split exclude domain list and then tunnel everything else. When the traffic hits the ASA terminating Anyconnect it then routes internally and follows the default route in the GRT through our Palo’s so we have great visibility, control and logging of their traffic.
Note this only matches and overrides 0.0.0.0 - if you have other prefixes in the ASA’s RIB it will follow those as normal and you cannot append “tunneled” to a prefix other than 0.0.0.0.
- We used to do this, hair pin our traffic through our ASA & SFR module. On top of this we also force all the local subnets to be sent to HQ, where it gets blackholed. This is to ensure users cant access anything on their local network. Seem extrememe but that’s how we did it.
As for the FTD, We’re only running an SFR module so cant tell you about full FTD, but on the SFR module all traffic goes through, we have a global block as well Security intelligence.
- Now we’ve moved over to umbrella so many users hair pin via HQ. Umbrella works like charm.
Attach your ACL to a vpn filter in your group policy. Attaching it to the outside interface does nothing
*edit - don’t forget to allow access to your internal networks for stuff like dns, otherwise if you only allow http/https, they won’t be able to resolve the hostnames. I typically allow all access internally (permit ip to your internal address space), but you can dial it in as much or as little as you want.
You are absolutely right, we do have corresponding ACL in ASA like this:
access-list outside_access_in extended permit tcp object RemoteUsers any object-group HTTP
access-list outside_access_in extended deny ip object RemoteUsers any log
So you see we already allow only the port defined in that HTTP group to go anywhere, but block all other ports.
Is this the best practice, though?
The default rule has to be block, lol.
Best practice for what? Are you asking if you should block all traffic except http? If so, then you should block everything except for http, https, and quic.
You’d be surprised how many places have their default rule set to allow or put an ACL in front of the default rule to allow all.
The 2 ACL rules I listed is already doing “block all traffic except http”. I just would like to see if anyone would do it differently… lol.