Hy guys I've two questions to submit to you:

1) Is there a way to read the destination ip address of a tcp packet in transit between two hosts with nat enabled?

2) Is there a way to scan a subnet situated "behind a nat"?

Thank you in advance for your answers.

1) You can see the current source or destination addresses of any IP packet in transit if you're able to sniff the traffic.

You won't be able to tell if the packet has been subject to NAT, with one exception: some application protocols make direct references to endpoint IP addresses, and in those cases the contents of the packet may reveal the NATed IP address. FTP does this (which is why NAT breaks FTP unless the NAT gateway has an FTP ALG), and so does SIP (which is why SIP clients usually have STUN support).

2) If the subnet is NATed because RFC 1918 addresses are being used (which is usually the case) then no, you typically won't be able to scan the subnet since there's no way to route packets to hosts in such networks.

By itself, NAT does nothing to prevent scanning or otherwise improve security. It is perfectly possible to NAT outbound traffic (with or without overloading) while still accepting inbound traffic to the IP network(s) behind the NAT gateway. However, if the network consists of non-routable addresses, there's no way to get the packets to the gateway in the first place.

To amplify on what Ser Olmy said, if your sniffing point is on the "private network" side of a NAT router, you will be able to see the (public) destination IP address, but if your sniffing point is on the public side, you won't.

An RFC 1918 address matches one of these patterns: 10.x.x.x, 172.16.x.x through 172.31.x.x, or 192.168.x.x. Any IP address in one of these ranges is not permitted as a destination on the public Internet, and will be filtered out by any well-behaved router. The way a NAT router works is to alter the source address of an outbound packet so that, when an Internet server responds, the reply will come to the public side of the NAT router. That router then looks up the target address in a side table it has kept, which recorded the substitution it has made, undoes that substitution to restore the intended target address on the private side, and forwards the reply to the correct computer.

This whole scheme was designed fairly carefully to make it impossible for a public-side host to discover anything about how the Network Address Translation was set up (thus its original name -- masquerading).