NAT and security levels Cisco ASA 5500 X series

[Jon Are Endrerud]

I have attached to files to this post (packettracer.txt and test-config.txt)

Im working with the X series of Cisco firewall and there is one basic thing that I dont understand. (this might be a stupid question).

If one interface is security level 90 and the other is level 10, and no NAT rules are configured for the given interfaces. Wouldnt the traffic be dropped, even if both interfaces has "any any ip" ?. On my older boxes with pre-8.3 fw, I always get the rpf-check failed message. On my new X series boxes with 9.x fw, the traffic flowes from one interface to another even if there are no NAT rules for the traffic.

What am I missing.

Thanx

Jon

[Jouni Forss · Accepted solution]

Hi,

I'll try to go through the things mentioned in your post.

First, the "security-level" applies in very few situations to the actual device behaviour. The things that have remained unchanged in the software for majority of the time are

• If you have NO interface ACLs configured then the "security-level" value of the interface determines towards which other ASA interfaces the users can connect to. Connections are by default allowed from higher to lower "security-level" interfaces but blocked in the reverse direction (lower to higher). So if the users are behind "security-level 100" interface they can typically connect towards any other interface on the ASA (some limitations apply that I will mention later)
• If you are attempting to allow traffic between 2 interfaces of equal "security-level" value then you will require the command "same-security-traffic permit inter-interface". Even adding ACLs without this command will NOT allow the traffic.
• If traffic is supposed to enter and leave through the same interface on the ASA (for example VPN Client traffic from "outside" to "outside" when the VPN Client user is browsing Internet) then you will need the additional command "same-security-traffic permit intra-interface" to allow that traffic. Again, even an ACL alone wont be enough to allow connections in this situation. You will need the mentioned command.

Now the things related to "security-level" that applied in the older software levels were atleast that if you were doing Dynamic PAT/NAT from lower to higher "security-level" interface then you needed a parameter "outside" at the end of the "nat" command you were using. Otherwise the NAT was not applied.

Now considering that you are using a new software level it means that the "security-level" should not really matter at all for the most part. Only situations are usually the last 2 points I listed above as typically each interface is configured with an ACL and "security-level" alone can not really be used to control traffic efficiently.

The RPF Drop that you mention in the post usually refers to a situation where the packet simulated with "packet-tracer" matches one NAT rule in the initial direction of the packet and matches another NAT rule in the reverse direction and is dropped because of that.

In the new software you wont really need any NAT configurations between your local interfaces UNLESS you specifically need to perform NAT but this usually is not the case. In the older software levels you usually required additional NAT configurations between local interface to get the traffic flowing. This was more due to how the NAT was implemented in the old software. The most typical problem you ran into when trying to allow connections from "inside" to "dmz" for example that you "packet-tracer" would match the connection to some "nat" configurations on the source interface and then state that there is no matching "global" for the destination interface. And this was usually avoided by adding a "static" command where you essentialy did a Static Identity NAT to avoid the connections matching to the original "nat" command.

Even though the new NAT configuration format have some parts that feel worse than the old format I still love the fact that I dont have to configure a huge amount of "static" configurations just to allow traffic to flow between local interfaces. Cisco also states that their aim is not really to use the NAT as a mechanism to determine what traffic is allowed. This should be left for the interface ACLs and such.

Hope I made any sense. Seems I wrote some things you werent really asking for even :D

Hope this helps :)

- Jouni

[Jon Are Endrerud]

Thanx for a very good reply.

Only one followup.

If I have a firewall with many interfaces. And I want to access the internet on one of them. Let say port

80 and 443. If I make an ACL with "network to any, tcp/80, tcp/443" Then that network will have access to every other interface on these ports. How do I assure that they only have access to the interface i want, and not all. Are "any" the wrong thing to use in this example ?
 

[Jouni Forss · Accepted solution]

Hi,

So basically your situation is that you want to generally allow connections to the Internet AND to some internal servers BUT still prevent allowing all other connections from the same source subnets to some other local subnets behind some other firewall interface?

In this case you would need to build the ACL in the following way:

• First allow traffic to the other local subnets that you want
• Block all other traffic to the other local subnets
• Allow all other traffic that you want to allow outbound from your network

An example situation could look something like this

You have a single LAN and DMZ interface on your ASA and also a WAN interface. You want to build rules for the DMZ interface which allow DNS queries fto some LAN Servers but deny all other traffic to the LAN. Lets also presume for examples sake that you have 2 different LAN subnets.

LAN: 10.10.10.0/24 and 10.10.20.0/24

DMZ: 192.168.10.0/24

DNS Servers: 10.10.10.10 and 10.10.10.20

object-group network DNS-SERVERS
 network-object host 10.10.10.10
 network-object host 10.10.10.20

object-group network LAN-SUBNETS
 network-object 10.10.10.0 255.255.255.0
 network-object 10.10.20.0 255.255.255.0

access-list DMZ-IN remark Allow DNS traffic from DMZ to LAN
access-list DMZ-IN permit udp 192.168.10.0 255.255.255.0 object-group DNS-SERVERS eq domain
access-list DMZ-IN permit tcp 192.168.10.0 255.255.255.0 object-group DNS-SERVERS eq domain
access-list DMZ-IN remark Deny all other traffic to LAN
access-list DMZ-IN deny ip any object-group LAN-SUBNETS
access-list DMZ-IN remark Allow HTTP, HTTPS and DNS to external networks
access-list DMZ-IN permit tcp 192.168.10.0 255.255.255.0 any eq www
access-list DMZ-IN permit tcp 192.168.10.0 255.255.255.0 any eq https
access-list DMZ-IN permit udp 192.168.10.0 255.255.255.0 any eq domain
access-list DMZ-IN permit tcp 192.168.10.0 255.255.255.0 any eq domain

access-group DMZ-IN in interface DMZ (this is needed when you attach the ACL to an interface for the first time. When new rules are added to the existing ACL this command is not needed in those cases)

The above ACL would allow DNS traffic to the DNS Servers and block all other traffic to the LAN Subnets. It would then allow HTTP,HTTPS and DNS traffic to any external network. This is because we already previously blocked all other traffic to the internal LAN Subnets therefore this last rule only applies to external networks.

If you need to allow additional traffic to LAN Subnets then you will need to add those rules before the "deny" rule in the ACL. If you get additional LAN subnets to which the DMZ does not need to connect to then you could add them to the "LAN-SUBNETS" "object-group"

Hope this helps :)

- Jouni

[Jon Are Endrerud]

Thank you for your help. Im ready to go...