NAT/tcpdump question

[desperado618]

I have a customer who manually nats his 192.168.0.0/24 network behind a 65.x.x.x address. When attempting to get out to the internet, Tracker shows the traffic being allowed and xlatesrc shows the translated address.
However when I go into the firewall(nokia IP260) and run a tcpdump on the external interface I can see the traffic leaving the firewall however the src address is the 192.168.x.x address and not the 65.x.x.x.
Shouldnt the tcpdump display the translated address?
Why would Tracker show that the traffic is being translated and the tcpdump on the external interface show the 192 address as the src?

 

[MaCinTof]

Hello,

In the SmartDashBoard you can NAT every object or networks.
You have 3 options for that what did your custommer choose ?

Cheers

 

[desperado618]

The object is not natted. There is a manual nat entry that says the following:
Source:Object name
XLATESRC:65.x.x.x
DST:Internet

None the less, the things that I am curious about is why would Tracker show a XLATED SRC and TCPDUMP does not show the translated address on the external interface traffic?

 

[abner78br]

Desperado618,

The reason TCPDUMP is not showing the XLATED address is because the translation is done after the data goes inbound in the firewall.

Regards,

Abner

 

[desperado618]

I am doing a dump on the external interface (the interface leaving the firewall, going to the destination). You are right, the translation is done after the data goes inbound (which would explain why I should not see the translated address on the inbound interface) however I am monitoring the interface that shows the traffic leaving the firewall destined to the internet.

 

[abner78br]

Desperado,

The reason why you cannot see the translated address in the external interface is because when the packet exits the network, the Checkpoint kernel translates the packet
back to the not XLATED packet using backward address translation. The kernel does this so the client will be able to match the reply IP address to its original IP address.

Regards,

Abner

 

[stooo]

if you use fw monitor rather than tcpdump, you should see how the packet looks as it leaves the interface

 

[desperado618]

Abner,
Thank you for replying however if Checkpoint actually changes the source nat address as it leaves the external interface, I have 2 small problems with tat procedure:

1. Since the device is nated at the firewall and, according to you, is denatted as the packet leaves the firewall, that would indicate that the firewall is natting this address for its own use only.

2. If the ip is really denatted as it leaves, it would indicate that te firewall is sending the denatted nonroutable address to the destination, which defeats the whole purpose for the nat.

What my client wants to to achieve is simple. He wants his internal addresses natted to his 1 internet address. By defination, this is what a source nat does. And all I want to know is why checkpoint Tracker shows the nat taking place and the tcpdump does not.

Regarding using fw monitor goes, since that is merely a cli representation of tracker (of vice versa) my quess is that it will show the natting. None the less, it will still not explain why the tcpdump does not.

 

[desperado618]

Please keep in mind that i never said that the traffic is not being natted. I only said that Tracker shows the natting and the tcpdump on the external interface shoows the rfc1918 address. I ONLY want to know if the dump should be showing the internally unroutable addresses and if so, why and how.

 

[abner78br]

Desperado,

Yes the packet is "deNATed" on the kernel. Try to see the FTP logs what is the source IP address of the connection and let me know.

If I understand your needs, you want to hide the source and not the FTP server, right?

I have a great CCSE training material explaining this NAT issues

Regards.

Abner