PIX conduit to ACL conversion question

[david.kane]

In a simple 3 legged PIX setup with a single conduit to permit access from the outside to a DMZ host, and no restriction on traffic in inside to outside connections; How do you convert the conduit to an ACL on the outside interface, that will permit the outside to DMZ host traffic, without stoping the return traffic of the inside to outside connections?

David

[l.mourits]

David,

You will need the following commands to permit traffic from inside to outside:

- nat (inside) 1

- global (outside) 1 interface

(that is, if you want to translate inside source adresses to the interface adres)

or:

- nat (inside) 1

- global (outside) 1

(that is, if you want to use a range of IP adresses to translate)

or:

- nat (inside) 0

(that is, if you are using public adresses on the inside and don't need to translate your inside source adresses)

For the access from the outside to the server on the dmz, you will at least need the following commands:

- static (dmz, outside)

(this command is always needed, to let the PIX proxy ARP, even though if the address isn't translated, in that case you will use the same address twice)

- access-list outside_in permit tcp any host eq 80

(this is just http, you will need to enter all required port numbers in this acl)

- access-group outside_in in interface outside

this should be it, if your config is as simple as you say, if you want you can mail your current config (remove passwords) and I can do the conversion for you, but of course, it's better to try yourself (just for getting gfamiliar with the new commands)

Hope this helps.

Kind Regards,

Leo

[david.kane]

Leo,

Thanks for the response, but I may have been too brief in my original question to give an accurate indication of what I am having a problem with. I would dearly like the config hints you supplied to work as simply as that, but I have some concerns that they may not. I will try and explain my understanding, and hopefully you or someone else may be able to correct my understanding, or point me in the right direction.

We have a fairly complicated 6 legged (one for fialover) PIX520 architecture at the present. I have to convert the PIX from using conduits to ACLs since we will be deploying a couple of Cat6000 firewall services modules that ONLY use ACLs into our environment. I read up on the ACLs and for all intents and purposes they appear to work exactly as router ACLs do, except thay are limited to traffic inbound to an interface. That is once applied to an interface they will filter traffic prior to it being put throught the stateful packet inspecting engine. As I see it I have the following problems. First, if an ACL is applied to the outside interface to permit inbound connections to our exposed DMZ hosts (hence replacing the conduits), this ACL will also prevent return traffic to legitimate outbound connections. Also if an exposed DMZ host needs to contact a inside host for any reason, then the ACL to permit this would then prevent the DMZ host's return traffic from reaching the outside interface.

I can solve the DMZ to inside ACL problem by creating a very specifically ordered ACL that:

A) permit traffic from the DMZ host to the inside host

B) deny the DMZ host to all networks directly connected to any leg of the PIX (other than the outside)

C) deny the DMZ host to all networks routed via a leg of the PIX (other than the outside)

D) permit any any

This will work, and I have seen at least one other forum message that indicate this is the way to do it. But this system seems to be a nightmare to manage. Firstly identifying all networks not outside the PIX will be fun, and then maintaining the ACL when new internal or Extranet networks are deployed will be a challenge.

But I can see no solution to the problem of applying an ACL to the outside interface to permit connections to exposed DMZ hosts. As far as I can see, ACLs on the PIX is not reflective as they have no keywork to support this feature. I had hoped that they would dynamically adapt like ACLs on a router running the firewall feature. But a quick test I did with a spare interface on a semi test PIX we have left me with the impression that they do not. So I cannot see an ACL solution to permit return traffic, and even if it was possible it would be highly unlikely that any ACL could perform the sort of protocol (FTP, H232 etc) fixups the stateful engine can.

Below is a simple config (fluff removed) along the lines of your suggestions.

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 DMZ1 security50

ip address outside 202.14.81.16 255.255.255.0

ip address inside 10.6.185.15 255.255.255.0

ip address DMZ1 172.31.1.1 255.255.255.0

global (outside) 1 202.14.81.15

nat (inside) 1 10.0.0.0 255.0.0.0 600 400

static (DMZ1,outside) 202.14.81.233 172.31.1.233 netmask 255.255.255.255 0 0

route outside 0.0.0.0 0.0.0.0 202.14.81.1 1

route inside 10.0.0.0 255.0.0.0 10.6.185.1 1

access-list acl_outside permit tcp any host 202.14.81.233 eq www

access-group acl_outside in interface outside

As I see it the above config will permit outside hosts to access the WWW service on the host 172.31.1.233 bacause of the ACL. Inside hosts will be able to send packets to hosts outside the PIX, but will recieve no return traffic. Replacing the access-list and access-group commands with a conduit will work, will this? Am I wrong? If so, could you explain how it permits inside hosts to establish connections to outside hosts. If I am correct could you indicate how to fix it to do so.

Any assistance will be greatly apreciated.

David

[l.mourits]

David,

Thanx for giving more in detail information.

I will first quote some of your last posting and give comments about the quote. After that I will try to explain more in detail.

We have a fairly complicated 6 legged (one for fialover) PIX520 architecture at the present. I have to convert the PIX from using conduits to ACLs since we will be deploying a couple of Cat6000 firewall services modules that ONLY use ACLs into our environment.

Should not be a problem at all, I have done several conversions from conduits to ACL's, also with complex configurations. Rule in this is, that it is always possible to convert to ACL's without the use of conduit commands.

I read up on the ACLs and for all intents and purposes they appear to work exactly as router ACLs do, except thay are limited to traffic inbound to an interface. That is once applied to an interface they will filter traffic prior to it being put throught the stateful packet inspecting engine.

This is indeed correct, with the difference that normal ACL's in IOS will be configured using wildcardbits (mostly the reversed from the subnetmask) and ACL in PIX-OS do use the subnetmask. So, in PIX-OS you will, for example use permit ip any 10.1.1.0 255.255.255.0 and in a IOS ACL you will use permit ip any 10.1.1.0 0.0.0.255 (just an example to show the difference)

As I see it I have the following problems. First, if an ACL is applied to the outside interface to permit inbound connections to our exposed DMZ hosts (hence replacing the conduits), this ACL will also prevent return traffic to legitimate outbound connections.

Not correct, the inbound access-list on your dmz interface will not prevent response-traffic from returning. Instead, the statefull inspection takes care of response traffic.

If configured correctly all traffic that is permitted from outside to dmz, can return from dmz to outside. If you that the hosts on the dmz can initialize traffic from the dmz to the outside you will have to need the appropiate nat and global commands in place to do the right translation (if needed) or to prevent translation (nat 0)

I can solve the DMZ to inside ACL problem by creating a very specifically ordered ACL that:

A) permit traffic from the DMZ host to the inside host

B) deny the DMZ host to all networks directly connected to any leg of the PIX (other than the outside)

C) deny the DMZ host to all networks routed via a leg of the PIX (other than the outside)

D) permit any any

I do not see the use of your first rule A, because in the end you permit ip any any, so any IP traffic will be permitted, except for the two deny rules in it.

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 DMZ1 security50

ip address outside 202.14.81.16 255.255.255.0

ip address inside 10.6.185.15 255.255.255.0

ip address DMZ1 172.31.1.1 255.255.255.0

global (outside) 1 202.14.81.15

nat (inside) 1 10.0.0.0 255.0.0.0 600 400

static (DMZ1,outside) 202.14.81.233 172.31.1.233 netmask 255.255.255.255 0 0

route outside 0.0.0.0 0.0.0.0 202.14.81.1 1

route inside 10.0.0.0 255.0.0.0 10.6.185.1 1

access-list acl_outside permit tcp any host 202.14.81.233 eq www

access-group acl_outside in interface outside

Then your questions about the provided part of your proposed config above

As I see it the above config will permit outside hosts to access the WWW service on the host 172.31.1.233 bacause of the ACL.

Yes, this is indeed correct :-) Also, returning (established) traffic will be permitted because of the statefull inspetion and the static command in place

Inside hosts will be able to send packets to hosts outside the PIX, but will recieve no return traffic.

Correct that they will be able to initiate traffic from inside to outside due to the nat and global command, but not correct on the statement that the returning traffic wil be blocked. Returning traffic will be able to get back, due to the statefull inspection engine and the xlate table entrie created.

Replacing the access-list and access-group commands with a conduit will work, will this? Am I wrong?

It is not recommended to use ACL's and conduits on the same system, so, I would not do this, besides, there no need to use conduits anymore, if everything else is configured the right way.

With all this said, I will come to the point that (I think) worries you.

What you state is this:

Also if an exposed DMZ host needs to contact a inside host for any reason, then the ACL to permit this would then prevent the DMZ host's return traffic from reaching the outside interface.

Let's take this as example:

A host on the dmz will need to contact a host on the inside, in this example I use your example addres, normally the appropiate command would be:

static (inside,dmz) 172.31.1.233 172.31.1.233 netmask 255.255.255.255

access-list acl_dmz permit ip host 172.31.1.233 host 10.6.185.100

(just took an inside address to explain)

access-group acl_dmz in interface dmz

You might indeed think that this config would prevent traffic initiated from the outside interface to the host on the dmz from travelling back, since the rule deny any any is applied to every ACL. But I don't believe this is the case, in my humble opinion returning traffic is passed, even with this ACL, but I have to check (I'm not able to do a test setup right now)

Am I correct that this is indeed your concern?

Kind Regards,

Leo

[david.kane]

Leo,

Great reply, thanks for taking the time. I did miss the PIX ACL subnet mask to IOS ACL wildcard bits different, that would have been fun to try and debug. Phew.

I want to quote you now and reword it to make sure I understand you correctly.

Not correct, the inbound access-list on your dmz interface will not prevent response-traffic from returning. Instead, the statefull inspection takes care of response traffic.

If configured correctly all traffic that is permitted from outside to dmz, can return from dmz to outside.

At first glance it would appear that an ACL on the DMZ interface would block return traffic to a permitted outside to DMZ connection. If I understand you corerectly, then you are stating that return packets are NOT inspected by the ACL and are instead handled by the stateful inspection mechanism. If so then my worries are for naught.

I guess I will have to do what I said in another post in this conversation, and lab this. If I lift the bonnet maybe I can figure out how the engine works. I just wish there was some doco on this.

David

[pcomeaux]

Hi David -

In response to part of your question - "How do you convert the conduit to an ACL?", you could use the Output Interpreter on the TAC website.

https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl

If you paste in your Pix configuration, this tool will check your config for problems and also convert your conduits to ACL entries.

Once it converts the conduits for you, you should review the new ACLs so you can be sure the ACLs support your security policy.

Maybe you have already tried it. If not, customers that try it really like the information they get from this tool.

peter

[david.kane]

Peter,

Thanks for you suggestion. This is my second attempt to reply to your message, I aan't see the first, so if this is a duplicate response please ignore it.

I did run our PIX520 config throught the output interpreter, and it gave me some ACLs. The ACLs required some trimming, and whilst doing this I started to have some concerns. I tried CCO for information but came up blank, so this conversation was begun. Whilst reviewing the generated ACLs I became concerned that they would filter traffic exactly as they were written; thereby allowing the specified traffic, with the implicit (if not explicitly coded) "deny any any" blocking all else. How would return traffic to connections estabilshed from other interfaces get back? The forum message http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.ee9b8ed seems to confirm my fears, but faith in Cisco and Leo's statement that he has got this to work OK gives me hope that I am misunderstanding PIX ACLs.

Please feel free to comment further, it may help me or others in the same boat. Without any definitive Cisco doco on how PIX ACLs interact with the firewall's other security mechanisms, I guess I will have to lab this and find out first hand. I will pull a PIX from our test LAN (the apps guys will not miss the Internet) and try it out.

Thanks again,

David

[pcomeaux · Accepted solution]

Hi David -

Leo has done an excellent job addressing your exact configuration questions.

Let's look at the ASA - adaptive state algorithm - that is at the heart of the pix for more details to answer your questions above.

Let's step through a scenario -

1 - Packet is received on an interface

2 - Is packet part of existing flow?

Yes - accept the packet and foward.

No - continue through this routine

3 - Does ACL exist on interface?

Yes - process against ACL

No - skip to step 5

4 - Process packet against ACL on interface.

Permitted by ACL - pass traffic and create state

Denied by ACL - drop and log if needed

5 - Since no ACL exists and no state exists, use the security levels associated with interfaces to determine behavior.

Higher to lower interface?

Yes - Permit and create state

No - Drop and log if needed

The above example does not take into account proper translations that need to be setup.

I will look for a more detailed example of the ASA behavior on CCO.

Give me your thoughts on the above.

thanks

peter

[l.mourits]

David,

First want to say that I'm very glad that Peter Comeaux from Cisco (CCIE) gives a more in detail description of the exact behaviour in his reply, and acknowledges my statements.

Glad we could help you out on this one. Also believe this is an important discussion, cause I agree with you that the information on this behaviour can not be found on CCO (I did look for it several times, and could not find it either). I would like to remember you of the importance of the rating system for this forum :-)))

If you are able to create a lab situation, this is great, and an absolute recommedation. Most important thing is to keep thinking about the translations which do apply, cause that's were most configurations do fail. But, as said before, if configured properly, there's no need for any concern, cause it will work fine, and you don't need to worry about the returning traffic.

Good luck with your conversion.

Have fun and kind regards,

Leo

[l.mourits · Accepted solution]

David,

In addition to my previous reply, I can tell you that I found a very interesting document on CCO, which discibes the behaviour of ASA for the PIX series.

Please take a look at this URL:

http://www.cisco.com/en/US/partner/products/sw/secursw/ps2120/products_configuration_guide_chapter09186a00800eb0b3.html#1008066

Especially look at the column: "How Data Moves Through the PIX Firewall" within this document.

This explains and proves the behaviour which Peter and I have stated within this discussion. The most important thing to realize in the behaviour of ASA is that it does not provide the returning traffic for ICMP, so, if you are testing with ICMP echo's (ping command) this will not work, and you might think that your config does not work. So, when you are going to test, please do not use ping test, because this will not work, test with UDP and/or TCP only.

Can't think of anything to be more complete in this thread :-))))

Kind Regards,

Leo

[david.kane]

Leo and Peter,

Top work guys, and the info was spot on. To finish off this conversation (yes I knmow it is just an excuse to have the last word) I must eat a little humble pie.

I did lab the issue by pulling the test LAN PIX out and starting the config from scrath, and low and behold it worked just like everyone told me. I didn't doubt you, just I didn't understand it fully. I then wondered why my previous quick test on the same PIX before I rebuilt the config from scratch had failed. Then it dawned on me that I had broken "network engineering 101 rule 1 - don't only use ICMP as a test". I was ping testing the host, added and ACL, and could no longer ping. So I assumed "ACL broke the return traffic" - WRONG (as Leo pointed out). The ACL simply took precidence over the conduit that permitted the non-session based ICMP return traffic which the ASA (I know its name now) could not implicitly handle. I only finished the lab just before knowck off time so I didn't get a chance to update you till now.

Thanks for the effort, you finally brought me into the light.

David