Global access lists will apply to all interfaces in an inbound direction. In your interface ACL, you are denying any traffic that is incoming on the INSIDE interface that has a destination IP of 192.168.2.1.
You state here that the “rest is permitted” but you don’t have a permit any any statement at the end of your Gloabl-acl access list. I assume that is a typo.
In this scenario, if you have an incoming packet to the INSIDE interface with a destination IP of 192.168.2.1, it will be dropped. Actually, both access lists (interface and global) deny it, but the interface access list will always take precedence over a global access list. So in this scenario, it is the ALL_INBOUND access list that blocks the packet.
Hi Rene,
I have one doubt on ACL, When we allow traffic from outside to inside ..Do we need to allow packet on INISDE interface as a outbound direction OR… only OUTSIDE inbound direction ACL will serve this purpose..?
In order to allow traffic from the OUTSIDE interface to the INSIDE interface, the access list you create must be applied on the OUTSIDE interface in an inbound direction. If you were to apply it on the INSIDE interface in an outbound direction, the incoming packets would be blocked.
The rule that says “traffic from a lower security level to a higher security level is blocked” would drop packets before they even reached the INSIDE interface for your ACL to take effect.
I have few questions regarding inbound rules for ASA.
Quoted from this chapter. "When you create an ACL statement for inbound traffic (lower to higher security level) then the destination IP address has to be: - The translated address for any ASA version before 8.3. - The real address for ASA 8.3 and newer."
Can I permit inbound traffic from Outside to Inside instead of DMZ?
How could client from Outside know the real address in DMZ or Inside? Aren’t all the addresses are always being translated?
Yes. You can permit inbound traffic from a lower security interface to a higher security interface. This is the case for Outside to DMZ as well as Outside to Inside.
The client from the outside doesn’t need to know the real address. The client needs only to know the translated address. However, you as an administrator know the real address in the DMZ, so when you add the ACL, you don’t use the outside address, but the real address. The client will still use the translated address to reach it, but the ACL will reference the real address.
Yes you can do that, but it will apply the access list in a particular way. Specifically, this command would be applied to all traffic that matches the INSIDE_OUTBOUND ACL that is moving in an outbound direction on the INSIDE interface.
In this case, the outbound keyword is relative to the specific interface we are looking at, which is the INSIDE interface, which is E0/0.
So, if you were to apply the command you suggest, then all traffic exiting the E0/0 interface would be permitted, except for HTTP connections destined for the 192.168.2.2 IP.
However, if you were to apply just this access list, it wouldn’t change the default behavior of the ASA. By default, an ASA will use security levels to determine if incoming traffic is allowed to be routed to a particular outgoing interface. By default, an “inside” interface has a security level of 100, and an “outside” interface has a security level of 0.
By default, incoming traffic on an interface with a higher security level can egress an interface with a lower security level. However, the opposite is not allowed. So by default, incoming traffic on an “inside” interface is allowed to egress an “outside” interface, but the opposite is not allowed. Take a look at the following lesson for more info on this:
In order to configure an exception to this default behavior, you must assign an access-list in an inbound direction on the interface with the higher security level. Your command issues an ACL in an outbound direction so it doesn’t override the default behavior. Does that make sense?