FWSM and filtering with access-lists, in/out per interface and NAT questions

[wilson_1234_2]

I have a question about Firewall Switch Modules for the 6509, I am looking at a config that my company has and had the following questions:

Question 1:

If I have two layer three intefaces on the switch and they are both firewalled with ACLs, with an ACL inbound and outbound on each interface, would the traffic specifically have to be allowed on all four access-lists, would the connection be stateful as in an ASA appliance, the lower security level should be able to establish a connection on the higher security level?

For example, If I had a machine on interface 1, 1.1.1.100, trying to get to a sql box on interface 2, 2.2.2.100 (1433), if that connection is not specifically allowed in one of the four inbound or outbound ACLs (implicit deny all) on the interfaces, would the connection get filtered?

Int 1

ip address 1.1.1.1

nameif One

security-level 10

Int 2

ip address 2.2.2.2

nameif Two

security-level 20

access-list One_in extended permit ip any any
access-list One_out extended permit tcp host 2.2.2.100 host 1.1.1.100 eq smtp

access-list Two_in extended permit ip any any
access-list Two_out extended permit tcp host 1.1.1.1 host 2.2.2.100 eq telnet

access-group One_in in interface One
access-group One_out out interface One

access-group Two_in in interface Two
access-group Two_out out interface Two

Question 2:

I have noticed that there are many nat0 statements applied, but no other natting (nat/global) is being done. Why does there need to be an exemption if no other natting is being done?

nat (Corporate) 0 access-list Corporate

access-list Corporate permit ip any any

nat (Engineering) 0 access-list Engineering

access-list Engineering permit ip any any

Question 3:

I have noticed that almost all of the filtering is being done on the outbound direction on the ACLs, with most of the interfaces having "permit ip any any" applied inbound. Typically the filtering is done on the inbound so the device does not have to process traffic that is going to be filtered anyway. Why is it the opposite in this application? Is there a valids reason to do it this way?

[varrao]

Hi Wilson,

Lets take your queries one by one.

1st Query:

On FWSM, you would need an ACL, whether going from higher to lower or from lower to higher security interface. So yes, you would definitely need to permit the traffic in the ACL.

ACL's can be apoplied in inbound and outbound directions, let me explain:

(just an example)

access-group out-in in interface outside  (this would filter traffic coming into the outside interface  outside<-----------traffic)

access-group out-in out interface inside  (this would filter traffic leaving or going out of inside interafce inside-------->traffic)

So the best thing is to apply a filter close to the source, so that traffic is filtered before entering the firewall, but it all depends on their requirement, if they aere already doing it for the rest of the traffic, they would need to add it for the new traffic as well.

2nd Query:

That is called nat-exempt, it would not nat the source defined in the acl going to that specific destiantion, in your case:

nat (Corporate) 0 access-list Corporate

access-list Corporate permit ip any any

any source going to any destination from Corporate interface would not be natted, or in otherwords the real ip address would not be changed, so the destination would see the packets coming from the real ip address.

this would help further:

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a008046f31a.shtml

3rd Query:

Now this is something, which is very much requirement based, if the want to do it for outbound as well, i ahve explained in you in the 1st answer the purpose of inbound and outbound and totally depends if they hacve any such requirements.

Hope I was able to clear out some of the doubts in your mind, do let me know if you ahve any other queries.

Thanks,

-Varun

[wilson_1234_2]

I reallt appreciate your reply,

On question 2, I am with you on the NAT and NAT exempt, my question is pertaining to the need for the Nat Exempt, if there is not other NATing in the config.

The only reason I can see to add these lines would be as precautionary (in the event someone adds NATing at some point), because there is an exemption for all interfaces that is applied to "ip any any" whch would mean that nothing is getting NATed. Also, there is no NAT/Global natting configured, so there is nothing to be exempted from.

[varrao]

Hi wilson,

This might clear out things for you:

http://www.cisco.com/en/US/customer/docs/security/asa/asa82/command/reference/no.html#wp1746857

Even in a scenario where you have these two nats configutred on the ASA:

nat (corporate) 0 access-list 101

access-list 101 permit ip any any

nat (corporate) 1 0.0.0.0 0.0.0.0

global (outside) 1 interface

Then always the nat-exemption rule would take preference of the dynamic pat. And if you have nat-control enabled on firewall then you would definitely need to nat the source, if you do not want to nat source, use nat exempt.

Thanks,

Varun

[wilson_1234_2]

I was unable to get to that document, but I still do not see the reason for the nat exemption.

nat-control is enabled in the FWSM, but the only nat configured are the exemtion rules, nothing else.

For each interface, there is an exemption rule with

nat (x) 0 access-list X

access-list X permit ip any any

If there is no other NAT configured, why are the expemtion rules put in place? What NAT are we expempting from?

[Jon Marshall]

If nat-control is enabled then you must do something with NAT, whether that be actually translating the addresses to other addresses or simply exmepting them from NAT.

A more relevant question would be if you only had nat exemptions everywhere then why run nat-control at all ?

Note i am not suggesting turning off nat-control without a full understanding of what is happening on the FWSM.

Jon

[wilson_1234_2]

excellent, than you Jon.

From your response then you also see no reason for the Nat exemption rules.

Do you have any thoughts on the ACLs as far as filtering inbound or outbound?

Currently thre are two rules each in the interfaces. The common application at this company is to filter on the outbound, wheras it makes more sense to me to filter on the inbound.

[Jon Marshall · Accepted solution]

Whether you need nat-control is difficult to say without knowing the full config of the FWSM but if there are only nat exemptions then it does seem like you could simply use no nat-control. Perhaps there were some NAT translations setup beforehand that have since been removed, it's often things like that then make it confusing later on.

As for acls, yes in my experience inbound acls are by far the commonest way to filter traffic. I have used outbound acls for specific purposes but quite rarely. It does seem slightly weird that you have acls applied inbound that permit ip any any because basically you are now making the firewall do more work by passing traffic through the FWSM only to drop it with an outbound acl.

There may be a logical reason for this but just as easily it could be that the person who set the FWSM up was not that familiar with it. Again it's difficult to say without understanding the full topology and traffic flows.

Jon

[wilson_1234_2]

Thank you Jon, you confirmed my thoughts on this as well.

I appreciate your reply.

On the first question, does the stateful connection possibility get removed when an ACL is applied in both directions on the interface?

Hopefully that is clear, but the stateful connection as I understand it, is that when a connection is attempted from a higher secuity level interface to a lower level security level interface , that connection can be established even though there is no specific inbound rule on the lower level interface, allowing a connection between the two endpoints.

Usually as in an Internet connection from inside to outside. When that is the case, there is usually no outbound filtering on both inside and outside interface.

I am wondering if applying an ACL outbound on both the inside and outside interfaces in the above example, would kill the stateful nature of the connection, due to the implicit deny on the ACL.

If the ACL is applied outbound one these interfaces, then the connection is only allowed if it is permitted in the ACL and there would be no "stateful" connections. Is this correct?

[Jon Marshall]

No you don't bypass the stateful nature of the firewall. The key thing to remember is that the state is kept for the return traffic and using both inbound and outbound does not stop this happening.

Couple of things to note -

lower to higher security level by default is not applicable on the FWSM. It is on the ASA but on the FWSM you still have to explicitly allow it.

An example might help -

you have an inbound and outbound access-list on the outside interface and you want to connect from the inside to a web server on the internet. The packet sent from the inside will be checked against the outbound acl on the outside interface. If it is permittted it will be sent to the web server. When the web server sends the return packet it is not checked against the inbound acl on the outside interface because the firewall has an entry in the state table for this connection and so will allow it. So by having an inbound and outbound acl on the outside interface you have not stopped the stateful nature of the firewall.

You raise an interesting point though. Where i am slightly unsure, and don't have a firewall to test with, is using the above example again but this time there is an inbound acl on the inside interface. The packet sent from inside is checked against the inbound acl and if permitted i would expect an entry into the state table. I am not sure now whether the outbound acl on the outside interface is also then checked before sending the packet out. Note that this still wouldn't stop the stateful nature of the firewall because reutrn traffic will still be allowed but i am not 100% sure on whether the outbound acl is checked or not.

Jon

[wilson_1234_2]

Ok, sorry jon, but want to make sure I understand,

I got what you are saying about the stateful nature of the ASA connection, but, are you saying the FWSM does NOT have a stateful connection, so any connection inbound and out bound has to allowed with ACLs?

[Jon Marshall]

Sorry to confuse the issue.

The FWSM is a stateful firewall just as the ASA. The main difference with the FWSM in terms of acls is that on the ASA by default traffic is allowed from a higher to a lower security interface by default. On the FWSM this is not the case so if you wanted to allow traffic from the inside to the outside you still need an acl on the inside interface that allows it.

However, return traffic is allowed on the FWSM just as it is with the ASA.

Jon

[wilson_1234_2]

Jon,

Would your last statement be the reason for, on the FWSM to have an ACL applied in both the inbound and outbound direction?

The company I am working for has this type of application on all of the SVI interfaces on the FWSM.

They have the ACL on the inbound direction set to permit any any, and are filtering in the outbound direction, although not all of the filters are like this.

Some of the interfaces have the filter detialed in both directions.

I find this very hard to follow and keep track of.

What is the typical application of ACLs for the FWSM?