TAZ Forum Community

4: TCP, UDP, NAT and PAT as the PIX see’s it.

In part four I will cover how the PIX handles TCP and UDP protocols, how static and dynamic translations work, how TCP interception features work and how to configure Dynamic NAT’s, Static NAT’s across one interface and multiple interfaces.

Almost the entire world uses Internet Protocol (IP) to communicate between computers, networks etc. An IP connection between two devices is known as a session. A session predominately uses one of two protocols, TCP or UDP.

From a PIX point of view TCP is very easy to inspect as a TCP ‘packet’ follows a very strict and well defined set of rules and has a very obvious start point and end point, and also makes it very clear what protocol the payload consists of.

UDP on the other hand is a very difficult protocol to inspect for the PIX as it has no clear beginning, flow state, payload information or end.

*The definition of Outbound and Inbound traffic differs from the normal definition as far as the PIX is concerned. When dealing with a PIX Inbound traffic is deemed to be traffic coming from a less secure interface to a more secure one (one with a lower security level to one with a higher level) and Outbound traffic is deemed to be traffic flowing from a more trusted interface to a less trusted one. Usually this will be INSDIE to OUTSIDE but this may not always be the case*

Transmission Control Protocol

TCP is a connection-orientated, reliable and high performance protocol that works at the transport layer (see herefor a definition of the various layers). It is reliable due to the fact each packet has a sequence number that is incremented each time a packet is sent or received and the packets are acknowledged once they are received to indicate to the sending device the packet has reached its destination satisfactorily. Due to the nature of TCP the PIX (or anything else) can see what state a current TCP connection is in at any given time as each header has various ‘flags’ is can set to indicate what type of packet it is and what is going on in the connection.

When a TCP Session from a host on a more secure interface (for the duration of this paper we will use the INSIDE interface) is started, the PIX creates an entry in the session state filter table. As its name suggests the session state table is used for the PIX to keep tabs on the state of any given session.

The PIX can monitor a TCP session in real time and is constantly aware of what packets are going where and (if configured to do so) what is in the payload of each packet.

When the session is initiated the PIX allows the packet out, but adds the Source Address, Source Port, Destination Address, Destination Port, and a random TCP sequence number, Flag (SYN, SYN-ACK etc) in to the session table. When a packet is returned to the sending IP address, the PIX is aware of what stage the connection is at and what is expected to be returned, so a valid packet would now be addressed to the sending hosts, IP address and correct source port, is from the correct IP address and Source Port, has the correct sequence number and the correct flag (in this case a SYN-ACK).

If any one of the above details are incorrect the packet is dropped.

SO to put it in easy terms with a very simplified header:



This is the essential information that would be in the header. The PIX would then enter this information in its State Table.



When the return packet came back it would expect to see this:


So the PIX checks the source IP and Port of this return packet to see if it has previously been sent any data, it looks to the session table and sees that something has indeed been sent to 67.1.1.1 to port 139 – it sees that this was sent by 10.10.10.20 from Port 34252 and then checks the destination IP of the return packet, 10.10.10.20 going to Port 32452 – so far so good – now it looks at the Flag, sees it is a SYN-ACK, due to the rules of TCP a SYN-ACK follows a SYN so when it looks at the session table for the connection it will expect to see a SYN flag – yep, all is good so far – now it looks at the Sequence number, the return packets Acknowledgment Sequence number should be the sending hosts sequence number incremented by one, 12346 – the PIX checks the state table entry and expects to see 12345 – yes all is good.

This packet meets all the requirements to be allowed through and will be sent on its journey.

*There is more to take into consideration, such as Access Rules, Fix-up protocols, Deep packet inspection etc but that is for later on, for now we will ignore them and just look at it from a Stateful Inspection point of view.*

As this session has not completed the ‘Three-way handshake’ that governs how TCP will connect two hosts together, the connection is known as an embryonic connection or a ‘half open’ connection.
No data will be sent between the two hosts until the connection is properly established. The PIX can be configured to terminate embryonic connections after a set period of time and to limit the amount any one host can have open. Once the entire three-way handshake has been completed the embryonic counter is reset for that particular connection.

There is a lot more to TCP but this paper is about how the PIX looks at and handles TCP sessions, not how TCP works. You can read this for more information on how TCP works.

User Datagram Protocol (UDP)

UDP is considered to be an efficient but connectionless protocol as unlike TCP there is no three-way handshake, session monitoring, error checking etc. Some people call it a ‘fire and forget’ protocol as once the data has been sent the sending station has no way to check if it ever reached it destination or not. There are no sequence numbers either.

For these reasons the PIX has a difficult job to try and secure a network against UDP packets….it has no sequence number to verify, no SYN, SYN-ACK etc Flags to check…the PIX has no way of knowing what state a UDP session is in, if it has ended etc so must take other measures to secure UDP traffic.

The PIX creates a ‘UDP Slot’ whenever a UDP session is initiated from a more secure interface to a less secure interface, any subsequent UDP packets that match the details in the UDP Slot are allowed through, ACL permitting.

As the PIX can’t tell when a UDP exchange has ended it starts a counter when a packet leaves, the default is 2 minutes. If a return UDP packet has not been received that fits the parameters in the UDP Slot then the slot is closed.

All UDP packets have to meet the same Stateful Source IP & Port, Destination IP & Port prerequisites that the TCP packet do, but as there is no sequencing it is relatively easy to spoof a UDP packet and maybe even get it through the firewall.

The main defence against UDP is the session timeout.

TCP Intercept and Connection Limits

Denial of Service (DoS) attacks are relatively easy to conduct due the amount of scripted software available for download today. For this reason it is in our interest to set connection limits for all incoming connections and all embryonic connections.
There are four common limits we can set:

1. TCP Maximum Connection limit – this limits the amount of connections a real IP host can have open concurrently
2. Embryonic limit – an embryonic connection is a TCP connection that has not completed a three-way handshake between the source and destination hosts.
3. UDP Maximum Connections – limits the maximum amount of concurrent UDP connections a real IP host can have open
4. Connection Timeout – The amount of time before an idle/embryonic connection is closed


SYN Flooding

As mentioned earlier, when a host uses TCP to communicate with another host it initiates a three-way handshake. Amongst other things, included in the three-way handshake are various flags that indicate the state of a connection.

When a host first makes contact with another host it sets the SYN flag in the TCP header, the receiving host the sets the SYN and ACK flags in the return packet, the first host sets the ACK packet in the subsequent packet.

A SYN flood is where we send a packet from a spoofed IP address to a host with the SYN flag set. The receiving host will send a SYN ACK packet back as expected but as the initiating IP is spoofed, there is nothing to receive the packet, hence the ACK flag that our server is waiting for to complete the third part of the handshake never comes back to it, if we flood the server with these SYN packets we will soon fill its buffer up as it will be keeping all connections open awaiting the ACK packets that will never arrive. This is what we call an embryonic connection and why we should limit the amount of them!

There is a very clever defence mechanism in the PIX to stop SYN Flooding should we reach our embryonic connection limit. If we set an embryonic limit that gets reached during a DoS attack, it would be pointless if the PIX drops all incoming SYN packets as then the DoS attack would still be successful, likewise the PIX is not about to let all SYN packets through!

To prevent the DoS attack from working the PIX uses what is know as TCP Intercept.

TCP intercept is a feature whereby if the embryonic connection limit is reached the PIX will assume responsibility for all incoming SYN packets on behalf of the server whose limit has been reached.

When a SYN packet comes in the PIX will log all pertinent state information as normal (Sequence number etc), respond with an empty SYN ACK packet and then drop the original SYN packet.
If the relevant ACK packet comes back from the server and all the state table information checks out the clients SYN segment is sent to the server and the three-way handshake takes place with the PIX and internal server instead.
Once this three-way handshake has been completed the connection will be allowed as normal.

TCP Intercept proved to be a very CPU intensive procedure and could still potentially result in a DoS state. To avoid this issue Cisco came up with a feature called SYN Cookies.

SYN Cookies

‘SYN cookies’ is a procedure PIX version 6.2 and later will use in place of TCP intercept.

When a SYN packet comes in and after the embryonic connection has been reached the PIX will still take over the three-way handshake on behalf of the server only instead of keeping stateful information like it does with TCP intercept, it will make a mathematical HASH or the destination IP, destination port, source IP, source port, sequence number and a secret key. This is then placed in the packets header in the form of a cookie and sent back to the initiation host with the relevant SYN ACK packet.

As the PIX is the only thing that knows the secret key, only the PIX will be able to decipher the return cookie

No state information is kept by the PIX thereby keeping its state table free and taking up no memory space.

When the initiating host responds with the expected ACK packet the cookie will still be in the packet header. The PIX extracts this cookie, deciphers it and calculates if it is a response to a previous SYN ACK sent out by the PIX, if so the PIX will attempt to open a connection to the server.

SYN cookies is by far a more manageable method of handling embryonic connection overflows.

The commands for all of the above are very very simple and are used with our NAT and Static commands.



Notice the 0 and 25 at the end of the above command. The 0 sets the maximum TCP connection limit to Unlimited (this can be substituted for a number of your choice) and 25 sets the maximum embryonic connections for to 25.

*If you do not specify any limits when you use the NAT and Static commands the PIX default both to unlimited*


UDP

As we know UDP is not a stateful protocol and does not use flags to keep track of the connection state.

However, we can still be flooded by UDP connections/packets from spoofed IP addresses when we have Static NAT’s and/or PAT’s so it is a good practise to limit the number of UDP connections we will allow to a single server.

The syntax is similar to the TCP method:



As you can see we simply specify the protocol and the maximum amount of UDP connections that the server can have, in this case we are saying that 10.10.10.10 can have a maximum of 100 udp connections at anyone time.

A more realistic command may be:



Which says that 10.10.10.10 can have unlimited TCP connections, a maximum of 25 embryonic connections and a maximum of 100 UDP connections


Network Address Translation

As mentioned in Part two, NAT is a method to reduce the amount of external routable IP addresses an organization needs and also to hide the internal IP addresses from outside viewing.

When configuring NAT remember that an interface with a higher security level can access an interface with a lower security level unless they are explicitly denied.
The Nat and Global commands go hand in hand with each other.
If you want to enable a lower security level interface to access a higher security interface then you must have the relevant access rule permitting it and a static NAT / PAT translation.

The PIX supports both Static and Dynamic translations.

Static Translation
Is a permanent one-to-one translation, or mapping, between an IP address on a more secure interface to an IP address on a less secure interface. You can only statically NAT one external IP address to one inside IP address, i.e. if you NAT 80.80.80.81 to 10.10.10.20 – when traffic arrives on the OUTSIDE interface, ACL permitting, it will be directed to 10.10.10.20. 80.80.80.81 can only now be statically NAT’d to this IP address and no other, otherwise the PIX would not know where to send the incoming traffic. This is different from Port Address Translation (PAT) which can be translated to more than one IP address and will be covered later on.

You would typically use a Static NAT when you host a web server that sits on an internal IP. Obviously you want your external IP of the Web Server to always be the same, if you Static NAT it to the internal IP of the server you will ensure that when someone browses to the outside IP they will always be translated across to the correct web server.

The syntax for a Static NAT is:



At first glance the above command could seem confusing but look at it this way:

(inside, outside) 80.80.80.81 10.10.10.20

Firstly you specify the real interface that the server is attached to, in this case our web server is on the INSIDE interface.
Secondly specify the interface that the mapped IP address is on, in this case the OUTSIDE interface – then specify the mapped IP address.
Next we specify the real IP address of the server and its netmask.

Just remember the mapped interface and IP are in the centre of the command, and the real interface and IP go at either end of the command.

A Static NAT can also be used to translate entire networks and is known as Net Static.



The above command will Nat the entire DMZ subnet to an IP address in the 80.80.80.0/24 subnet when passing traffic to the outside interface. This comes in handy when you have multiple subnets on a single interface.


Dynamic NAT

Dynamic NAT’s are used when no outside host will have to initiate a connection to come into your network(s). Typically a dynamic NAT is used for a normal office LAN that has not external facing servers/services and just need normal outside connectivity i.e. to the internet.

Firstly we must identify which internal hosts we want to NAT to an external IP address. This can be an entire subnet, specific hosts or everything attached to a certain interface. We then give these hosts a group number, usually starting from 1.

After we have decided what hosts will be eligible for translation, we must then decide what external IP’s we want them to use when they talk to the outside world. And assign these external IP addresses to the same group as the internal hosts we have just defined.



nat = Tells the PIX we are defining hosts to be NAT’d.
(inside) = Tells the PIX where the hosts are located, in this case they are on the INSDIE interface
1 = Group number for these hosts
10.10.10.0 = the subnet we want to configure NAT’ing for. In this case every host between 10.10.10.1 and 10.10.10.254 will be translated to an external address when sending packets out of the OUTSIDE interface.
255.255.255.0 = the subnet mask that defines our subnet.

Now we have told the PIX which internal hosts we want to NAT, we must now tell it what addresses it can use to translate them.



The syntax is very similar to the NAT command we gave earlier.

global = Tells the PIX that we are defining what global (external) IP addresses it can use.
outside = Tells the PIX that these global IP’s are to be used by the OUTSIDE interface
1 = The NAT-ID group. This must be the same as what we defined in the NAT command for the inside interface. We can have multiple groups. For example if we hade two different internal subnets we want to NAT to two different sets of external IP’s, we would make two groups, one for each subnet. This would then tell the PIX, if the inside host is in group 1 then he gets an external IP from global group 1 and if the internal host is in group 2, he gets an external IP from group two.

Finally we tell it the range of IP’s available on the OUTSIDE interface. These are issued out on a ‘first come – first served’ basis until they are all used up. If the PIX administrator has not configured the PIX correctly and all the available IP addresses are in use, then some hosts will not have external connectivity, until IP addresses become available.


Multiple Interfaces and NAT

Multiple interfaces are configured the exact same way as a single interface to enable NAT on them. There are a few options when it comes to the Global Addresses though.

You can either use a new group by using a different NAT-ID number and then assign the group a new range of external IP’s or you can share one Group of external IP addresses between multiple interfaces.

Remember we assign the Global addresses to the OUTSIDE interface, so any traffic passing through the OUTSIDE interface will pick-up a Global IP address. We could have five other interfaces all sharing the same NAT-ID and as long as there are IP addresses available from the pool, they will all pick-up an IP before traversing to the outside world.



In the above example we have configured three different subnets on three different interfaces to all share the same pool of addresses when traversing the OUTSIDE interface. As long as there are IP address available all hosts will have external connectivity.

We don’t have to share the same pool, as mentioned a few paragraphs above we can use more than one NAT-ID.



As you can see each interface is in a different NAT group and has a different pool of IP addresses to chose from when traversing the OUTSIDE interface.


Port Address Translation (PAT)

PAT is more commonly used on small to medium sized office LAN’s as most small business don’t have a pool of external IP addresses to use.

As mentioned earlier a Static NAT is only god for one IP address and one host, you can’t Static NAT a single IP address to two different hosts.

If we only have one IP address (or very few) we need to use PAT

One single external IP can theoretically be used for up to 64,000 inside hosts and can be a virtual IP address which is different from the IP address assigned to the interface.

PAT can be used in conjunction with NAT if you so desire.

There are a few applications that have problems with PAT such as some VoIP protocols and various other multimedia applications so you may want to research PAT if you have multimedia applications on your network(s).

If we want to use an IP address that is different than the IP address we assigned to the interface we set it up in the same way we have been setting NAT up, except we only use one IP address in the Global pool with a 32 bit subnet mask.



Each time a host on the 10.10.10.0 network sends data out of the OUTSIDE interface the source port in the frame header is dynamically changed by the PIX to a port greater the 1024.

For this example we will say a host with an IP of 10.10.10.10 has sent data to the internet and used port 3000 to send it. When this packet arrives at the PIX it will change the source port in the packet header to one greater then 1024, for now we will say it is changed to 2000.

Then when data arrives on the outside interface destined to 80.80.80.92 and with a destination port 2000 the PIX knows that is substituted the source port of 2000 for the host with the IP address of 10.10.10.10, it will now change the destination port back to 3000 as otherwise the host would not accept the packet and sends the data on its way. (TCP and UDP inspection is still carried out as normal as per the Stateful Algorithm Rules)

We can also use the IP address of the interface if we have no spare IP addresses left.



The above command speaks for itself, instead of specifying an IP address or a pool of IP addresses, we tell it to use the IP address assigned to the interface

PAT will take place in exactly the same way as mentioned above, except it will use the interfaces IP address.

Just as we can with NAT we can assign multiple subnets to a single IP address in the same group or we can have a single IP address per group.



Here we have two different subnet attached to the INSIDE interface but we want to separate the external IP's they use. So now the 10.10.10.0 network will PAT to 80.80.80.83 in the normal way and the 10.10.20.0 network will PAT to 80.80.80.84 in the normal way.

We can back up an IP address we are using for PAT with another one to keep in reserve should too many hosts want external connectivity at the same time.



The hosts on the 10.10.10.0 network will use 80.80.80.83 for external connectivity until the port pool is at maximum usage, then the PIX will start using ports from the 80.80.80.84 address.


We can even use a PAT IP address to argument a NAT global pool in case we run out of ‘NAT’able’ IP addresses.



So now all hosts on the 10.10.10.0 network will use the global pool of 80.80.80.81-90 and be NAT’d across to these until there are no more available, then the 80.80.80.91 address will be used to PAT any more hosts the require external connectivity.

This is a sneaky method if you only have a few external IP addresses but don’t want to PAT all hosts or if you have ran out of external IP’s and don’t want to buy another subnet’s worth of them.


Identity NAT

As stated earlier NAT can be set to one of two settings, either all traffic will be NAT’d unless an explicit rule exists to say a certain IP address does not need to be NAT’d or no traffic will be NAT’d unless an explicit rule exists to say a host will be NAT’d.

Identity NAT, also know as NAT 0, allows us to map our IP addresses transparently so that our internal host’s IP addresses are visible to the internet without any address translation occurring. All hosts that are behind a higher security level with translate themselves to all lower interfaces.

Typically this is used when we have Internet Network Information Centre (InterNIC) registered IP addresses (external IP’s) on our internal network that we want people to be able to connect to directly from the internet without any NAT taking place.

Keep in mind that an ACL will still need to be applied to say traffic can pass from a lower level security interface to a higher one.



This command tells the PIX to not translate 80.80.80.234 to anything when passing traffic to and from it.

Remember to put a ’0’ after the interface instead of NAT-ID group and to add the necessary ACL to allow the PIX to pass traffic to the host.


Port Redirection (Static PAT)

If we have a secure web server, a non-secure web server and an FTP server on our internal network that require connections to be initiated from the outside how would we set this up?

We could static NAT 3 different IP Addresses to the servers and apply the relevant ACL’s which would allow outside users to connect to all of out services.
Whilst this solution would work and is a viable one in some cases, it is a waste of IP addresses.

Would it be better if we could share one IP address between all the hosts? But didn’t we say that we could only static NAT one IP address to one host?

Since all three of our servers use different ports, we can static NAT & PAT one IP address between any amount of hosts that require the use of different ports.

We basically tell the PIX, if traffic comes in to x.x.x.x on port xx then send it to x.x.x.x on port xx

So say we have an external IP of 80.80.80.132 and an FTP server with the internal IP of 10.10.10.50

We tell the PIX:



The above command tells the PIX that any tcp traffic that comes in to the outside interface destined for 80.80.80.132 that is ftp (on port 21) should be sent to the inside interface to the host that has the IP address of 10.10.10.50 on the ftp port (port 21)

If you spend a few seconds looking at the above command it will become obvious what it is doing.

For an added layer of security we can use a non-default port on the outside interface and redirect it to the default port, like so:



The above command tells the PIX that any tcp traffic that comes in to the outside interface destined for 80.80.80.132 on port 12345 should be sent to the inside interface to the host that has the IP address of 10.10.10.50 on the ftp port (port 21)

Usually due to the time issue when scanning all 65.535 ports most casual vertical scans do not exceed the well known ports ( 0-1024), so by opening up port 12345 to an incoming FTP request we could fool a casual attacker into thinking we do not have an FTP server on the network.

*A vertical scan is a scan that checks the ports of a certain hosts, a horizontal scan refers to a ‘ping sweep’ or a scan that tries to determine active IP addresses*

An ACL would still need to be configured to allow the external connections to pass through the PIX.

So for our three servers a sample configuration could look like:



We can change the first set of ports to anything we want, but unless the default ports on the server have been altered we need to use the defaults for the second port number we enter.

We can use the service name for common services such as FTP, HTTP and HTTPS or we can use the port number should we so wish, the PIX sees it all in the same way.



Summary

Well if you have read all of this, Congratulations as it took me 5 days to write!

Due to the extraordinary length and detail in this paper I will summarize the process a packet will follow when it arrives at the OUTSIDE interface of the PIX.

1) Packet arrives at the PIX
2) The PIX first consults the Access Rules of the interface the packet arrives on.
3) The PIX makes a routing decision to determine which interface to send the packet out of
4) The source address of the packet is checked against LOCAL ADDRESSES in the translation table
5) If an entry is found in the translation table, it is translated as per the configuration
6) If an entry is not found the PIX will look for a translation match in the following order:
1) nat0 access-list (NAT Exemption) to see if the host is exempt translation or not
2) Static (Static NAT) will look through the static NAT table starting at the top until it finds a match
3) Static TCP / UDP (PAT) – will examine the static PAT table starting at the top until it finds a match
4) nat (NAT-ID access-list) this is policy NAT which will be covered later
5) nat – regular NAT, best match
6) If no match is found at all then the packet is dropped

The PIX keeps a State Table for all TCP and UDP connections and a Translation Table for all NAT translations.

Current TCP/UDP and NAT connections can be seen with the sh conn and sh xlate command respectively.

The PIX uses SYN cookies to prevent SYN Flooding, a form of DoS or if you have a version prior to 6.2 it will use TCP Inspection

You can Port Redirect traffic from a non protocol default port to a protocol default port.

The NAT and GLOBAL commands argument each other and will not work on individually.

You can only Static NAT one IP address to one host but you can Port redirect fro one IP address to many hosts.




Next paper will be Access Control and Content Filtering.

Thanks for that nokia

Hi Nokia,

first of I just want to thank you for these fantastic series of tutorials on Cisco Pix. If only the authors broke it down the way you did then so many people would be straggling to make sense of it all. really thanks for your time and effort.

I have a couple of questions I would like to ask if I may:

1)if one has a range of public IP from their ISP or whatever then is it possible to apply them on one interface only say the OUTSIDE interface, how would one interface serve multiple IP, I understand the concept on a router but can you say a little about the process on the pix, especially with public IP range.

2) If a host A on the internet wants to communicate with a host B on a private INSIDE interface, you will need to permit it on the OUTSIDE interface's ACL, but do you also need to permit host B to talk back to host A on the INSIDE interface acl, or does the session state table help avoid such duplication of ACLs. for example, when we try to ping out from INSIDE interface to the internet, even after applying the ACL on the INSIDE, we sometimes have to apply the ACL on the outside interface to otherwise it times out,
on the inside, permit icmp host C to any
on the outside, permit icmp any to host C

are we doing anything wrong or do we have to apply it on both interface because there is no session state entry, because ICMP is mostly stateless?
is it a session state thing or an interface security level?

3, if you use a public ip as a static pat, can you also use it for PAT-ing as well. Or is it a case of once you have a static pat entry, you can only add more static pat but obviously mapped to another port?



thanks nokia, look forward to your reply

Hi TwiceAsNice,

Thanks for your comments.



If you have assigned external IP addresses to the Outside interface then the PIX won't route them in the traditional way. The fact that you have assigned them on the Outside interface would mean that it will translate them to an internal host. So it will take the packet coming in destined for say 80.80.80.80, look in its translation table and see where it should send them - it will then change the packets destination IP to the relevant internal one and send it on its way.
I think this is what you are asking?



The PIX handles ICMP differently to normal IP traffic.

For normal traffic if you wanted an external host to talk to an internal one then you would only have to permit the traffic on the Outside interface ACL - by default the Inside interface can send anything out of an interface with a lower security level (Outside being 0 and the lowest you can get) so there is no restriction on internal -> external traffic, hence the return flow for your traffic would be unhindered.

The exception to this is if you have place an ACL on the Inside interface to restrict the traffic flow - obviously you would need to add the relevant entries.

As for ICMP, by default the PIX does not let any ICMP in through the Outside interface - so an internal host can ping out with no problems but the ICMP reply would not get back in - it is this reply you need to allow.



I’m not too sure what you are asking here?

I think you may have meant if you are using a public IP for a static NAT can you use it for PAT?

If so, then no you cant - the reason being if you have configured a static NAT then you are telling the PIX that EVERYTHING coming in to that external IP is to go to this internal IP - obviously the ACL will tell the PIX what type of traffic is allowed.

PAT is different because you are not saying that everything should go to such and such an internal host, you are saying that everything destined for such and such a port is to go to such and such a host - so the IP address may not change but the destination port number will and it is this that will inform the POIX of where to send the traffic to.


Hope it helps?

Hi Nokia thnx for the quick reply,

the Answer to 1 and 2 make sense but ignore Q3 since I was confusing myself. I have a one more questions please.


Do example1 and example2 mean the same thing? in that they will no nat inbound and outbound traffic to 10.64.60.0/24

example1
--------------------------------
nat (INSIDE) 0 access-list NONATINSIDE

access-list nonatINSIDE extended permit ip 10.64.60.0 255.255.255.0 10.64.60.0 255.255.255.0
-------------------------------

example2
-------------------------------
nat(INSIDE) 0 10.64.60.0 255.255.255.0
-------------------------------

Hi,

Sorry for the delayed reply, I have only just seen this for some reason.

The first example you posted is not a valid command - the ACL is permitting IP from the 10.64.60.0/24 subnet to the 10.64.60.0/24 subnet......the subnets are both the same....

The second example tells the PIX not to NAT any traffic going to any host on the 10.64.60.0/24 subnet.