PIX firewall 'clear xlate' command

[a.manosca]

From the PIX firewall documentation, it was mentioned that the "clear xlate"

command should be used after changing or removing the alias, access-list,

conduit, global, nat, outbound, and static commands.

Question: Does this command clear (or refresh) them all at the same time?

If this is true, what will happen to the existing translations if I only changed the

access-list policy and then issued the command? or in general, what is the

effect of frequently using the "clear xlate" command? I've looked into the PIX

command reference but the "clear xlate" command has no other optional

parameters.

TIA.

[p-hogan]

Hi

Initially the translation (xlate) table has no entries, it is dynamic.

As users pass through the firewall and are translated, via static or global commands, then the xlate table grows.

If you change a static command, for example, the PIX will look in the xlate table for an entry before reverting back to the static command. So you have to clear the xlate table to aloow a fresh, and correct, table to build.

It is reuired also for access-list, alais and conduit commands for similar reasons.

Paul

[a.manosca]

Thanks for the reply. I do have some follow-up questions.

Assuming there are existing entries in the xlate table,

which are active translations, and then I re-configured the

access-list, will the active nat sessions be dropped after I

issue the clear xlate command? Thanks again.

[p-hogan]

The access-list will start to deny/permit straight away.

Were the changes in the access-list related to any of the global or static commands? If so you will need to clear xlate.

When you clear xlate, all sessions will have to re-establish.

It may be safer to clear xlate table to ensure new parameters are taken.

Paul

[a.manosca]

It's a good thing that you mentioned that the ACL will

take effect right away. But isn't it a bit confusing because

you mentioned:

"So you have to clear the xlate table to aloow a fresh, and correct, table to build. It is reuired also for access-list, alais and conduit commands for similar reasons."

I was thinking that the PIX's ACL config function is similar to

the router IOS configuration, wherein, after you have entered the ACL

entries and applied it to the interface, it immediately takes effect.

I would appreciate if you could further clear things out.

Actually, the firewall is yet to be configured. My colleague

is inquiring about the effect changing ACLs once the PIX is

already running. I have already listed test procedures to verify

this but, as you can see, I'm looking for some information from

the NetPro forum. Thanks again.

[p-hogan]

The ACLs work in a similar way to the IOS but:

-they use subnet masks instead of wildcard masks

-you can remove any single ACL entry without dynamically affecting/deleting the rest of the ACL.

Yes they will only take affect when applied to an interface.

It is said to be good practice to clear the xlate table when any of the listed changes occur although changing the access-list and conduit command may not necessarily need a clear xlate table.

[adimatteo]

You can do a "clear xlate local " and it just clears that local address.

[shannong]

FYI...I work with the Pix extensively and have NEVER used clear xlate due to an ACL addition/change. I talking about several hundred changes at least.

You MUST use clear xlate when doing static, nat, global, and alias changes IF the host in question already has translation information in the table. If working with a specific host and you don't want to interrupt other communications, you can use "clear xlate local 192.168.1.1" for the single workstation inside address and "clear xlate glob 123.123.123.123" to clear the IP a host is/was being NATted to. Of course, if the global IP is a PAT address then you will be affecting many hosts that are using it.

[a.manosca]

Hi guys, thanks for all the information that you've provided.

The PIX configuration and testing will start today

so probably I can verify all your inputs later. Just check out

this post again for any info. Thanks again for all the help.

[a.manosca]

I now have verified some information.

'p-hogan' and 'shannong' (if I may call you by that name)

were right about the ACLs. The ACLs immediately takes effect

without using the clear xlate command. However, I haven't

tested yet the static, nat and global commands.

If I may add another question to this post, the PIX command

reference gives the following description about the

'fixup protocol':

"Modifies PIX Firewall protocol fixups to add, delete, or change

services and feature defaults."

As you can see I'm new to the PIX firewall so these question

should really be easy for PIX experts out there. I believe

that with the ACLs, you can allow protocols like ICMP to pass

through the PIX. So we made some tests with FTP but we have

used ACLs to allow FTP to pass through. So what would be the

specific use of the fixup protocol in the PIX firewall.

I have also noticed that you cannot add other protocols

with the fixup protocol command (or maybe I just missed some

configurations). I tried adding "fixup protocol snmp 161"

but it was rejected. Or is it that with this command I can change

the port number for a spcific protocol like, for example,

fixup protocol smtp 8085?

Thanks in advance for any input.

[shannong]

Fixup supplies application layer inspection and intelligence for particular applications. The functionality is built into the Pix code and can't be modified for the most part save minor things like port changes.

Fixup for FTP is done to accomodate how FTP works. FTP actually use to ports, and it doesn't really use port 21 to send data. Some other port is negotiated after a handshake for data transfer. With Active FTP, the two hosts negotiate another port for data and the client connects back on that port. Because it is dynamic, you don't know what to allow in the Pix. The fixup inspection knows to look for these handshakes, NAT that traffic as well, and allow it back in the Pix. That's why you don't need to open anything other than port 21 for FTP on the Pix.

SMTP fixup restricts what SMTP commands the Pix will allow in. That's why ESMTP is troublesome on a Pix with this fixup enabled. It also scrambles the SMTP banner.

For the other fixup functions on the other applications, consult the documentation.

[a.manosca]

Thanks again for the reply. We have added quite a number of ACLs in the

PIX as per customer requirements. However, we wanted to test if the ACLs

are working so we have selected FTP for the test. First we wanted to verify

that we have no connectivity problems so we configured ICMP ACLs to

allow the outside host to ping inside. But with the customer's specs, there's

no translated address for the inside host (probably because the 'outside'

doesn't really mean the internet). The outside interface of this firewall is

connected to another network within the same company. So, I thought it's just

a sort of a simple routing function.

I have read some PIX firewall tech notes and most of the configs use

translations. With this, we were able to allow ICMP to pass through using

"static(inside,outside) 10.1.1.1 10.1.1.1 netmask 255.255.255.255 0 0".

Now we have tried the same for the FTP test but we were not successful.

Here's the ACL part:

access-list 101 permit tcp 10.1.2.0 255.255.255.0 eq ftp host 10.1.1.1

Did I miss something here? Any input is very much appreciated. Thanks.

[shannong]

If this access-list is on the outside interface and you're trying to access ftp on the inside host then it should be constructed like this:

access-list 101 permit tcp 10.1.2.0 255.255.255.0 host 10.1.1.1 eq ftp

[a.manosca]

That was really helpful. We were able to test it today and it worked.

For the meantime, we can only test FTP but FTP will not really be

permitted to pass through the PIX.

Below is a part of the ACL that will be used in the PIX:

access-list 101 permit udp 10.1.3.0 255.255.255.0 eq snmptrap host 10.1.1.1

access-group 101 in interface outside

static (inside,outside) 10.1.1.1 10.1.1.1 netmask 255.255.255.255 0 0

The objective is to allow SNMP traps to pass through.

Is the configuration correct? Also, it seems that the

static command is always required. Any comment on this?

[shannong]

Remember that access-list place source address/ports first then destination address/ports. IF snmptraps are destined to 10.1.1.1 for the 10.1.3.0/24 network, then construct the ACL like this:

access-list 101 permit udp 10.1.3.0 255.255.255.0 host 10.1.1.1 eq snmptrap

The easiest way to test this is configure a CIsco router on the outside to send "config" traps to the server. Everytime you enter configuraiton mode on a Cisco router and it can send a trap:

snmp-server community public RO

snmp-server enable traps config

snmp-server host 10.1.1.1 public

Generically speaking, statics are always required when exposing inside hosts (high security) to outside hosts (low security).

-Shannon