i think you have pool of real IP with GW and DNS so
no you don't need any NAT on the PIX . you just need to confirm the next with ISP
- the interface of the PIX which faced the modem has private IP (some thing like 192.168.X.X ) and sure the modem will be your GW in same range
- use one of the real IP which you get from the ISP to bring internet to you and assign it to the interface connected to the palo alto
- in the palo alto configure the interface which is connected to the PIX with other Real IP , configure default root to PIX and sure perform NATing for what ever Subnet you need to publish
i just wonder why you configure DHCP on the PIX , in such case PIX acting as next hub for your FW and may any L3 device even the FW acting as your DHCP server.
i such case my dear PIX act as a router , just route out subnets get from palo alto to outside and vice versa . in such senario NAT occured only on palo alto which already has real IP as i mentained before
First, I'm assuming you're focused on TCP. UDP has some differences, and I'm not as up-to-speed on that part.
I’m beginning to learn about nat and I was wondering why does NAT
translate a source port?
You're right to ask this question, and to be frank, it doesn't always need to. However, sometimes that translation IS required. Given that it is sometimes required, and given that the NAT system therefore needs to track source port for some traffic, and because there are efficiencies in doing something the same way every time, most NAT implementations don't make an effort to re-use the original source-port on the NATted connection.
Many (most?) protocols don't depend on the source port for TCP connections, so that's the simplest approach, and it rarely hurts.
Doesn’t a port represent an application that’s requesting a service?
It does, but generally the source port is not specified by the application. Instead it is assigned (somewhat) randomly. This is actually good, because before that was true it was way too easy to break existing connections by predicting the source port number (the "unreach" attack using ICMP DESTINATION UNREACHABLE packets).
So why must it be translated? Also what would happen if NAT
hypothetically didn’t translate the source port and two separate
machines on the same network sent out a message but had the same
source port?
The answer to your first question is in the answer to the second, so I'll take a stab at the second, and you share if it doesn't answer the first.
First, assume your NAT host only has one IP address (N) to translate to. Second, assume you actually have an extra coincidence where internal hosts A and B both try to communicate with external host X on port 80 with source port 17835.
- A's packets (when generated, before NAT) look like: src: A:17835, dst: X:80.
- B's packets (when generated, before NAT) look like: src: B:17835, dst: X:80.
After NAT, assuming no translation of source port:
- A's packets (after NAT) look like: src: N:17835, dst: X:80.
- B's packets (after NAT) look like: src: N:17835, dst: X:80.
Oops. They look the same. They particularly look the same to the remote host X. It is most likely to drop the packets associated with the second connection attempt because the sequence numbers are going to be wrong.
You also have a problem on the NAT host, as it can't tell the difference between the two either. It can only maintain one "connection" record with remote host X on port 80 per source port. It has to keep this record so it knows which internal host to translate back to when it receives an inbound packet. If the record corresponds to the first host to connect, then you would have the experience where A (the first host) has no problems, and B cannot connect.
If, more entertainingly, B's record in the NAT overwrites A's after the connection is built for A, then the NAT system will never forward X's responses to A (it only has B's record), and X will never respond to B (wrong sequence numbers / connection state) and nobody wins (communicates).
Let's be honest. NAT is a hack. It is an ugly hack, and we are either lucky it works (because we haven't rolled out IPv6 universally yet) or victims of its success (because it works well enough, people don't insist on IPv6 support).
Best Answer
Because they're in the same zone -- and thus the same subnet, the source must be rewritten to get the replies to pass back through NAT instead of being a direct reply.
When a local lan client attempts to connect to the public server address, the traffic will flow to the firewall. The firewall will rewrite the destination and forward the traffic to the local lan server address. If the firewall doesn't change the source as well, the server will see the source as being on the local lan, and it's replies will be sent direct to the local lan client using the local lan server address. Without it passing back through the firewall, the traffic will not make sense to the client (wrong tcp sequence numbers, and wrong IP address.)