Cisco ASA Access List outgoing confusion

[jesseworstnotepad]

Hello World, 

I'll jump straight to it:

When I navigate to the ASA Access Rules tab in ASDM, I am simply overwhelmed by the large number of interfaces and ACLs that we have ... namely, because I am in a enterprise environment. 

To really learn the lay of the land, I started by collapsing all the rules to only view the interfaces.

The reason I'm posting is because candidly I am confused by "outgoing" vs "incoming" rules. Can someone please explain the difference in context, giving examples along the way? 

By outgoing, do they mean traffic that is not considered response traffic? Or traffic that originates from an internal host that is ---- for example ---- originating traffic outbound ... not to be confused with traffic that is going out in response to a packet it received. 

Then I'd like to understand the same for "incoming" access lists as well. 

Here's an example, but feel free to you use any examples for explanation. 

Thanks,

Guy

[Seb Rupik]

Hi there,

Incoming/ outgoing relates to the direction of travel relative to an interface.

Say you have an ASA with two named interfaces OUTSIDE (connected to an ISP router and the internet) and LAN.

If I start a TCP session to a server hosted on the internet, the flow will be INcoming to LAN and OUTgoing on the OUTSIDE interface. The return traffic will be the reverse.

It is worth noting that the ASA is a stateful firewall, when the return traffic reaches the OUTSIDE traffic the state table is consulted before the ACL, therefore an established connection is permitted through. If this were not the case you’d need inbound rules permitting traffic to all your internal network with a destination port value of the entire ephermal range.

Also the ASA uses security-levels as a method of implicitly policing traffic without the need for ACLs. This means a new session inbound to an interface can never leave via another interface with a higher security-level without an ACL explicitly permitting it.

However as soon as you configure and ACL on an interface all traffic is at the mercy of the implicit deny irrespective of the security-level ‘gradient’.

Cheers,

Seb.

[jesseworstnotepad]

Seb,

Thank you for the clarification. There are still two items related to this that would help me understand a bit more:

1) I understand your explanation below about higher security to lower security, such as LAN to WAN interface, however, what about "outgoing" rules that have been created for a LAN interface (security 100), such as that represented below??? Can you explain the difference in those vs the LAN incoming rules??

2) Also, what is the point of explicitly creating all of these access rules, if at the second-to-last rule, that is the rule right before the implicit deny statement ---- is an ANY ANY PERMIT IP rule? Doesn't that allow all the traffic for that interface. I've highlighted it below:

Thanks for your patience!

Guy. 

[Seb Rupik]

LAN OUTgoing rules will be for traffic leaving the interface and entering the subnets connected to the LAN interface. I say subnets plural as there may be router somewhere in there.

As for the permit ip any any, that is normally a troubleshooting left over or evidence that someone has given up trying to get a traffic flow to pass through the ASA. Either way it should be removed. There is little point having the preceding ACEs with that present.

Cheers,

Seb.

[jesseworstnotepad]

Seb,

Thanks for clearly explaining. So I think I understand. As one last example, this is an illustration where someone put an ANY ANY IP PERMIT statement, after first defining a bunch of explicitly defining rules before it. This is for the "outside" interface. Is this also an example that defies logic? Have they given up here as well. It seems that they created a bunch of explicit rules, only at the end to put a ANY ANY PERMIT statement? No?

[Seb Rupik]

The benefit of the preceding rules is that they are recording hits which at least which in some fashion provides insight to the traffic traversing the interface without the need to implement netflow monitoring.

I'm curious to know what the remark says for the permit ip any any. Is it just "Allow everything" ??

Is the OUTSIDE interface internet facing? It is worth noting that if you are performing NAT on this interface, it is slightly less concerning as it is unlikely that traffic destined to a RFC1918 address will have got this far and be able to make use of the permit since you will have implemented dynamic PAT. Any devices using static NAT statements on this interface would be at risk from the permit statement.

Cheers,

Seb.

[jesseworstnotepad]

I'm curious to know what the remark says for the permit ip any any. Is it just "Allow everything" ?

There are no comments, it's for the outside interface, but correct me if I'm wrong, this statement allows ALL IP traffic to exit outside interface, regardless of protocol?

Is the OUTSIDE interface internet facing? It is worth noting that if you are performing NAT on this interface, it is slightly less concerning as it is unlikely that traffic destined to a RFC1918 address will have got this far and be able to make use of the permit since you will have implemented dynamic PAT. Any devices using static NAT statements on this interface would be at risk from the permit statement.

No, the outside interface is NOT internet-facing. I should note that this is an enterprise environment, so the outside interface actually connects to another router/firewall in the enterprise environment. There is no NAT on most of our internal firewalls (which are ASAs in context mode). 

I'm trying to understand the nature of how these "outgoing" policies are being leveraged in context. In a sense, they are all "internal" interfaces, whether outside/inside ... because there are upstream routers/firewalls that are public-facing. 

Our internet-facing gateways are maintained by another department in an international environment. All of the ASAs in context mode have a GRT (global routing table) interface that is used as a transit interface to route towards the Checkpoint firewalls ...which are internet-facing. It's kind of complicated in that sense, since we are an international company. 

Before I worked in environments, where I always had access to the public-facing firewalls, here I am mostly dealing with large ASAs in context-mode, which have numerous sub-interfaces that are trunked with VRFS to different places on big MPLS LAN .. probably using MP-BGP in the MPLS cloud, etc. 

Thanks for all your help. I think after your next response, you have adequately replied for sure! I was just uncertain why there were so many access list statements, only to end the list with a permit IP ANY ANY. Didn't make sense to me :0

Guy.