Solved: ASA access-list direction question

cisco8887 · ‎10-13-2015

Hi All,

I have just been investigating an issue on ASA for the past couple of hours.

Basically I have a static nat from outside interface to inside interface on port 5000.

Outside interface = 1.1.1.1
Inside interface = 192.168.1.1

Nat rule
Pat for any address from 192.168.1.0/24 to interface 1.1.1.1
Static nat for 1.1.1.1 on port 5000 to map to 192.168.1.1 5000

This should work as long as relevant outside acl is applied which was and I could see the packet passing through all hoops and getting denied on the inside acl in outbound direction rather than inboud !

Inside acl was setup for outgoing traffic as follow

Access-list inside_out extended tcp deny 192.168.1.0 255.255.255.0 any eq 25
Access-group inside_out out interface inside

So my question is :

The packet for the static nat was getting dropped because I had to add a rule on the inside_out as follow

Access-list inside_out extended tcp permit any 192.168.1.0 255.255.255.0 eq 5000

Why is this , isn’t the asa meant to receive the packet on outside in then pass it to inside in ?

Based on above , I am correct assuming in direction only applies when traffic received from local subnet directly attached to it and outside is when a traffic is going to it from an indirect network such as from outside out to inside in ?

Thanks

Jon Marshall · ‎10-13-2015

Okay, I think I see where the confusion is coming from.

An acl applied inbound affects traffic entering the ASA.

An acl applied outbound affects traffic leaving the ASA.

So a connection initiated from the outside to an inside host will arrive at the ASA on the outside interface and is entering the ASA so the inbound acl on the outside interface is checked.

If you had an acl applied outbound on the outside interface it would not be checked because the traffic is going in the other direction.

So continuing with the above if the traffic is allowed it then needs to be sent out of the inside interface to the destination.

And because the traffic is now leaving the ASA any outbound acl applied to the interface used to exit the ASA is also checked and for arguments sake lets say it is allowed.

Because the packet is allowed the ASA now makes an entry in it's state table.

Once the initial packet has gone through the ASA any return traffic is not checked against any acls applied to any interfaces because the ASA is a stateful firewall and it simply checks it's state table, sees there is an entry and so allows it.

For a packet going from inside to outside the same logic applies although traffic is allowed by default inside to outside without an acl.

Again for the sake of argument lets say you do apply an acl inbound and outbound to the inside interface and inbound and outbound to the outside interface.

The initial packet from the inside device is checked against the inside acl applied inbound (the outbound acl is not checked because it is the wrong direction). Assuming it is allowed the ASA then checks the outbound acl on the outside interface (again not the acl applied inbound on the outside interface because it is the wrong direction). Again assuming it is allowed the packet is sent on to the destination IP.

The ASA now makes a state table entry for this connection because it has been allowed through.

The return traffic will now be allowed without checking any acls. It doesn't matter that you have an acl applied inbound on the outside interface and an acl applied outbound on the inside interface because the ASA has a state table entry so it doesn't need to check these acls.

The key point is the direction of the initial packet in relation to the ASAs interfaces and the corresponding state table entry if the packet is allowed.

Just as a side note, usually with ASAs you have an acl applied inbound on the outside interface and that is the most common.

Optionally you may want to restrict what inside users can access on the outside so you can have an acl applied inbound on the inside interface.

Using outbound acls is not as common as inbound ones although there are certain cases where they can be useful.

So has the above helped clarify it ?

If not or you still have more queries please feel free to ask.

Jon

View solution in original post

Jon Marshall · ‎10-13-2015

If the connection is allowed through the firewall then the return traffic is automatically allowed because of the entry made in the state table.

The key work in the above is "through".

So if your inside acl had been applied inbound then the initial connection from outside would be checked against the outside acl and then allowed through because the inside acl is applied inbound so it doesn't apply.

The return traffic would automatically be allowed back ie. it would bypass the inside acl applied inbound because the ASA has an entry in the state table.

But in your case because the inside acl is applied outbound it is checked and because you hadn't allowed the traffic the connection did not go through the ASA.

The direction has nothing to do with whether the source or destination IPs are directly connected to the ASA.

Jon

cisco8887 · ‎10-13-2015

Thanks for coming back to me

i allowed the connection on inbound on outside interface but this did not work

I allowed any any on inbound inside and still did not work

i had to allow any to host inside on outbound acl for it to work

so i think above is not a correct statement

i am also further confused how inside traffic continued to go through asa as there is an implicit deny at the end of every acl and the outbound acl had no permit any any or permit inside subnet any

also no inspection was applied to inside interface so totally confused

Jon Marshall · ‎10-13-2015

I think you perhaps didn't follow what I explained or just as likely I didn't explain it very well :-)

So you allowed the connection inbound from the outside so it enters the ASA.

Nothing you do with the acl applied inbound to the inside interface affects that connection because the direction of the connection is outbound on the inside interface.

But an acl applied outbound to the inside interface will affect that connection because the traffic has not yet get gone through the ASA.

So until you allowed that traffic the connection was not allowed.

The return traffic for that connection however bypasses all acls because the ASA now has a state table entry so even if you had a line in your inside acl applied inbound denying the return traffic it wouldn't stop it.

In terms of why traffic continued through the ASA it is what I was saying before ie. once traffic is allowed through the return traffic is automatically allowed ie. all acls are bypassed.

So if the connection is made from the inside to the outside and is allowed then an acl applied outbound on the inside interface is not checked against the return traffic.

It is all to do with where the connection is originated from in relation to the ASAs interfaces and if the connection is allowed through the firewall then any return traffic is automatically allowed regardless of any acls.

Does this make more sense ?

Jon

cisco8887 · ‎10-13-2015

I think what i fully don't understand is how traffic flows through the asa

my understanding is this

when a packet from outside wants to go to inside as fresh traffic

it is checked against outside inboud and then pass to inside inboud where as you are saying it is inside outboubd

could you help me understand this please

also when the same traffic comes in on inbound outside, does it also pass through outside outbound before going to inside inbound for it to go to inside outbound again,?

Would the flow be inside outside and the outside in without passing through outside outside and inside inside,?

Jon Marshall · ‎10-13-2015