ASA/FWSM Newbie Confused

[networkguy09]

Hello,

I know very little about ASAs and FWSMs and work in an environment where we have both. Lately, I've been asked to get more involved in maintaining the firewalls, but no one will help me understand the basics. I've done some searching around and had little luck finding a good source of information for someone with very limited knowledge. Take in the fact we have multiple versions of each firewall, it adds to the confusion. Between the ASDM online help button in the ASDM and this forum I've gotten even more confused. I will try to lay out some of my basic understandings and areas where I need help.

First off, my understanding of an ASA vs a FWSM: ASA is a standalone device with more capabilities and features. FWSM is a module that goes in a chassis and provides similar functionality but with less capabilities and features.

Second, I do not understand the concept of security levels. I found virtually no information on this in the ASDM online help. I'm told that a higher security level can initiate any communication into a lower security level and that any access lists in place would not even be checked in this scenario. Based on what I've read here so far I believe this depends on which platform your talking about ASA or FWSM.

Third, I have intermediate understanding of access list on Cisco routers (still get confused understanding the difference between an inbound vs outbound access list) but I am wondering if the ASA/FWSM has a similar concept of inbound applied vs outbound applied. I've looked everywhere in the settings and can't determine how the access list are applied.

Fourth, This is a small matter, but some of our FWSM don't show a hit count in the ASDM. Other FWSMs and ASAs both show hit count.

That's pretty much it at the moment. I've been asked to build out context for a new network on a FWSM. My understanding of our setup is that we run in transparent mode/bridge mode (is that the same thing?) We defiantly run in a bridge mode where the user is on one vlan and must pass through the ASA or FWSM to reach his gateway (which resides on a different vlan). I understand that much. Also we pretty much use 100 security level for the "inside" vlan (The vlan where the user or server originates) and security level 0 for the "outside" or untrusted side. In the case of the context I've been asked to setup I've been told this is a special case where neither side is to be trusted. This begs the question of having same security levels and the implications in doing so. I've been asked to create access lists on both inside and outside where say the user is allowed to open a remote desktop connection to a server. They want me to specifically allow the return traffic via his high random source port. The information below comes from the ASDM online help and would suggest that an access list for the return traffic would not be needed. I know this is a lot to answer, but I'm just looking for some good accurate documents that will help me get started in understanding these concepts.

Access Rules for Returning Traffic

For TCP and UDP connections for both routed and transparent mode, you do not need an access list to allow returning traffic, because the FWSM allows all returning traffic for established, bidirectional connections. For connectionless protocols such as ICMP, however, the FWSM establishes unidirectional sessions, so you either need access lists to allow ICMP in both directions (by applying access lists to the source and destination interfaces), or you need to enable the ICMP inspection engine. The ICMP inspection engine treats ICMP sessions as bidirectional connections.

---

[Shrikant Sundaresh]

Hey NetworkGuy,

Sorry, Don't know your name . Welcome to the Cisco Support Community Forums.

I really appreciate the fact that you tried to research on everything, and I shall try to help clear out some of the doubts you have.

Concept of Security Levels:

The security level you set for an interface is the amount of trust (on a scale of 0 to 100) that you have in the users on that interface. So, as you mentioned, the Inside is generally 100 (since you trust you employees), and the internet facing interface is 0 (since all the bad guys are on the internet).

On ASA there are implicit ACL's on each interface. These have two acess-list entries:

Line 1: Allow traffic if the destination interface has lower security level than this interface

Line 2: Deny all traffic.

So the advantage for the higher security levels, is that they can initiate connections to ip's on security levels below them. But explicit access-rules (and NAT rules) would need to be defined if traffic needs to be initiated from lower security level to higher.

However, if an access-list is mentioned on a higher security level interface, then traffic will be matched against it.

As far as i know, the concept of security levels is same on both ASA and FWSM.

Inbound and Outbound ACL

Very simply, an ACL regulating traffic leaving the device is an outbound ACL. An ACL regulating traffic entering the device is an inbound ACL.

When you apply an ACL to an interface, you give a command like: "access-group acl_name in interface inside"

That command would regulate traffic entering the inside interface. Thus if you want to block your internal network from accessing a particular internet ip then that's the access-list where it should go. If you wanna block traffic from an Internet ip to an inside ip (ideally this would go "inbound" on the outside interface), you could create an access-list which says so, and add it out on the inside interface.

I didn't quite understand what you meant by: "FWSM don't show a hit count in the ASDM"

Bridge mode and transparent mode are the same.

Assigning same security levels does require additional configuration to be done, which would depend on your current config. I would suggest keeping the internal interface a bit higher than the external. The security-levels are just for your reference, and it is just a number to the ASA.

In the new context, I would suggest doing the following:

inside at security 1, outside at security 0.

access-list inbound on inside interface, allowing all traffic to the RDP server on the rdp ports.

NO access-lists on the outside interface at all.

This way, only return traffic for the RDP connection initiated from the inside would be able to come in.

The ASDM documentation you have pasted states the same in the first line: For TCP and UDP connections for both routed and transparent mode, you do  not need an access list to allow returning traffic, because the FWSM  allows all returning traffic for established, bidirectional connections.

Hope this helps. Feel free to reach out if you have any further queries.

-Shrikant

P.S.: Please mark the question as answered if it has been resolved. Do rate all helpful posts. Thanks.

[networkguy09]

Hi Shrikant, Thanks for taking the time to try and help me. Since I'm setting up a new network and context I decided to play with it and see how it works.

On ASA there are implicit ACL's on each interface. These have two acess-list entries:
Line 1: Allow traffic if the destination interface has lower security level than this interface
Line 2: Deny all traffic.
So the advantage for the higher security levels, is that they can initiate connections to ip's on security levels below them.

I see what you mean on the ASA. I checked one of ours and it does not have the "implicit allow traffic from higher to lower" It appears on our ASA however, that we have disabled that somehow because I only see it on the IPv6 rule base which is not being used. On the FWSM, at least mine in particular this is not the case. There is no rule like that. I tried changing security levels and no matter what I did, access list rules were required on both the "inside" and "outside" interfaces with the exception of return traffic which did not require a rule. The only except to that would be ICMP which did require rules on both sides explicitly stating ICMP communication was allowed. That would seem consistent with the documentation I quoted earlier.

The security-levels are just for your reference, and it is just a number to the ASA.

Is that really the case? On the ASAs you do have the "implicit allow traffic from higher to lower" I am still not sure what the security level actually does for you on the FWSM. I've seen similar threads on this forum where other users come to the same conclusion. As for the ASA, I wonder if the "implicit allow traffic from higher to lower" means that for example a use on one network, let's say 10.1.1.0/24 with security level 100, could initiate communication to another network, let's say 10.1.2.0/24 with security level 100 all without the access list even been checked because this is level 100 to level 100. Or would one network have to be a lower level, say 90 for this to work? One of my co-workers explained this is how the security levels work. I decided to test this on the FWSM. On my FWSM, using the above example (10.1.1.0/24 level 100 to 10.1.2.0/24 level 100) I had devices on each network with remote desktop setup. Each side tried to open a remote desktop connection. In each case the tcp to port 3389 was blocked by the access list deny any any. Changed one side to security level 90 made no difference. In any case, on the FWSM I never see a "implicit allow traffic from higher to lower" rule. So maybe the security levels really mean nothing on the FWSM?

In the new context, I would suggest doing the following:
inside at security 1, outside at security 0.
access-list inbound on inside interface, allowing all traffic to the RDP server on the rdp ports.
NO access-lists on the outside interface at all
This way, only return traffic for the RDP connection initiated from the inside would be able to come in

What we ended up doing is same concept but the RDP connection is initiated from the outside. So we have rules on the outside access list specifically allowing remote desktop from the networks that will initiate communication. Return traffic works without any rules on the inside. I'm still not 100% clear on how to tell if the access list is applied inbound vs outbound, other than how I specify the source vs destination. Wouldn't make much sense to have an inbound applied access list on the outbound interface that has my inside servers specified as the source.

[chelsea4ever]

Wonderful explanation Shrikanth. Thank u very much for ur contribution to this forum