cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
549
Views
10
Helpful
4
Replies

Outgoing ACL on OUTSIDE kills IPSec traffic ASA

Hi All,

 

Just the other day I created an outgoing ACL on my OUTSIDE interface on the ASA. The source is a couple of internal servers which I need to deny internet access to. The servers will have to exit other interfaces on the ASA so I thought that instead of creating 5 - 10 ACEs on the TRANSIT interface, I would stop the traffic when the servers tries to reach ANY destination via OUTSIDE.

 

I did the ACL like so (PERMIT for testing):
access-list OUTSIDE_access_out_2 line 1 extended permit ip object-group INTERNAL-SERVERS any
access-group OUTSIDE_access_out_2 out interface OUTSIDE

Right after applying the ACL, I lost reachability to a couple of endpoints reached via IPSec. I didn't validate if every IPSec was impacted. Removed the ACL - IPSec back to OK. Did it once again to verify if it was due to the ACL.

 

I can't find any clues to this behavior, either by googling or the config guides.

 

Anyone here who has seen this before?

 

The ASA is running 9.14(2)15 code

1 Accepted Solution

Accepted Solutions

Aref Alsouqi
Collaborator
Collaborator

You mean you lost connectivity from inside to those remote endpoints?, if so I would think this is expected. The ACL you applied would only allow the traffic from the servers defined into the object group INTERNAL-SERVERS to go out of the OUTSIDE interface. As there is an implicit deny rule on the ACL, any other traffic will be denied.

The way how I would deal with this scenario would be to create a couple of ACEs and apply them in inbound direction on the interface where those servers are connected. If you have already an ACL applied in the inbound you can just add the rules at the top, if not you would need to create something similar to this:

access-list INSIDE_IN extended permit ip object-group INTERNAL-SERVERS 10.0.0.0 255.255.255.0

access-list INSIDE_IN extended permit ip object-group INTERNAL-SERVERS 172.16.0.0 255.240.0.0

access-list INSIDE_IN extended permit ip object-group INTERNAL-SERVERS 192.168.0.0 255.255.0.0

access-list INSIDE_IN extended deny ip object-group INTERNAL-SERVERS any

access-list INSIDE_IN extended permit ip any any

access-group INSIDE_IN in interface INSIDE

That way you are allowing the INTERNAL-SERVERS traffic to reach the whole RFC1918 ranges but nothing else. So those servers won't be able to reach any public IP address on the internet. The permit ip any any rule at the end is needed to allow the other traffic to pass through. It is always a best practice to apply any deny rule closer to the source, that will save the firewall in this case from process further any traffic that would be denied.

View solution in original post

4 Replies 4

MHM Cisco World
Advisor
Advisor

...

MHM Cisco World
Advisor
Advisor

Sysopt connection permit-vpn,

This is by defualt enable, disable it to make asa not allow outside to inside traffic even if it come from vpn.

Now config acl that make only vpn can access to internal, 

Aplly this acl to outside ìnterfacr with in direction.

 

For acl you mention, why you need internal only access to vpn? By default the asa allow traffic from high to low secuirty level.

Aref Alsouqi
Collaborator
Collaborator

You mean you lost connectivity from inside to those remote endpoints?, if so I would think this is expected. The ACL you applied would only allow the traffic from the servers defined into the object group INTERNAL-SERVERS to go out of the OUTSIDE interface. As there is an implicit deny rule on the ACL, any other traffic will be denied.

The way how I would deal with this scenario would be to create a couple of ACEs and apply them in inbound direction on the interface where those servers are connected. If you have already an ACL applied in the inbound you can just add the rules at the top, if not you would need to create something similar to this:

access-list INSIDE_IN extended permit ip object-group INTERNAL-SERVERS 10.0.0.0 255.255.255.0

access-list INSIDE_IN extended permit ip object-group INTERNAL-SERVERS 172.16.0.0 255.240.0.0

access-list INSIDE_IN extended permit ip object-group INTERNAL-SERVERS 192.168.0.0 255.255.0.0

access-list INSIDE_IN extended deny ip object-group INTERNAL-SERVERS any

access-list INSIDE_IN extended permit ip any any

access-group INSIDE_IN in interface INSIDE

That way you are allowing the INTERNAL-SERVERS traffic to reach the whole RFC1918 ranges but nothing else. So those servers won't be able to reach any public IP address on the internet. The permit ip any any rule at the end is needed to allow the other traffic to pass through. It is always a best practice to apply any deny rule closer to the source, that will save the firewall in this case from process further any traffic that would be denied.

You're right, and I didn't pay attention as the ASA creates a new OUTGOING ACL for the new ACE. After all these year, this shouldn't have slipped - rookie mistake!