In article <dv1qvv$f5v$1@nsnmpen3-gest.nuria.telefonica-data.net>,
dan <x@x.com> wrote:
>So according to this, my question would be, why is the conection not done?
>In what part does the packet get lost?
>If I do a telnet to my own public address, this should pass the nat as a
>usual outgoing conection, right?

When the packet reaches the router, the router has to decide whether to
change the source IP from a private IP to a public IP, leaving the
destination alone (outgoing packets); or to change the destination IP
from a public IP to a private IP, leaving the source alone (incoming
packets). Often it makes that decision by looking at the routing table
and seeing which interface the packet is bound for, changing the source
IP if the packet is headed to the outside interface, and changing the
destination IP if the packet is headed to the inside interface.

Now, suppose your inside packet gets to the NAT device and it looks and
sees that the destination is inside and so decides the packet is
heading inward, and suppose it built the translation and sent the
translated packet towards the inside (instead of dropping it like a
Cisco PIX would.)

The hypothetical translated packet would have the destination's private
IP as the destination IP, and would have the private IP of the source
as the source IP. The destination would receive the TCP SYN packet, and
would reply with a SYN ACK. The destination IP of the reply would be
the source IP of the SYN packet, which is to say the private IP of the
originator of the connection. The reply would therefore go *directly*
to the originator of the connection, not to the NAT device.

But what does the SYN ACK reply look like when it gets to the connection
originator? It would have the originator's private IP as the
destination, and the target's private IP as the source. The
connection originator would go to look up the 5-tuple
(protocol, source IP, source port, destination IP, destination port)
in its connection tables -- and it isn't going to find it, because
what the connection originator sent out was a SYN packet to
the *public* IP of the target, not to the *private* IP of the target.
So the connection originator is going to drop the SYN ACK packet,
and the connection destination will retry sending the SYN ACK a few
times and will eventually time out the connection and give up.


If the NAT device had treated the connection as an "outgoing" one
instead of an incoming one, then the packet it would have sent
out the outside interface would have had the public IP of the
target as the destination, with a translated [public] IP for
the destination. But the packet would now be on the outside. *If* a
router along the way sent the packet back towards the NAT device,
and *if* the NAT device did not have even basic firewalling protection,
the NAT device -might- see that as an incoming packet and translate
the public destination into the private destination, leaving the
public IP it earlier assigned to the source in place. The target
would reply with a SYN ACK and that packet would have the public
that the NAT device earlier associated with the connection source,
so the packet would head towards the NAT device. What happens when
the NAT device sees that public destination? Well, in this
branch, we are hypothesizing that it will send the packet outwards,
retaining the public IP of the destination and changing the private
source to be the public IP of the source. Out the packet goes,
hypothetically gets looped back by something further out, NAT device
sees the public destination and hypothetically is dumb enough to
allow the packet through without basic security precautions... and
the packet would get to the connection originator in this situation.
The connection could actually proceed in this scenario, at the
cost of having every packet go outside the firewall and go some
number of hops before being looped back by something external.

So could it ever work? Yes -- but look at the combination of
circumstances required. The packets have to be redirected
by something outside (possibly with an ICMP Redirect generated
for each and every one), and the NAT device has to lack basic
security measures. And here's the hidden bit: for this to work,
the NAT device has to be leaving the port numbers strictly
untouched (e.g., "1-to-1 NAT", or a primative Port Address Translation
(PAT) in combination with the happenstance that the port
numbers don't happen to conflict with anything else already taking
place.) Because if the port numbers get altered when the NAT is
taken place, then again you will get conflicts where the 5-tuple
that reaches one of the machines is not the 5-tuple the machine
is expecting. Or the same thing for the NAT device if it has
any stateful protection *at all*.


> The router I use is a ziyxel which seems to be a bit weird.

Unless it an early model ZyXel, it very likely has some stateful
packet filtering, and you wouldn't be able to get this to work
even if by chance it followed the "treat it as outgoing and
have the next hop loop the packet back" scenario.


My strong recommendation would be to sidestep the whole situation,
by not using public IP addresses as destinations from the inside.
Instead use hostnames, and in -some- manner configure the name
resolution so that internal hosts know the hostname under the
private IP and external hosts know the hostname under the public IP.
For example if you were using bind9 as your DNS server, you could
use "split views". Or you might find that your NAT device has the
ability to translate DNS responses on-the-fly, handing each side
the IP it needs to know. (Cisco PIX is an example of a device
that has this facility.)