Hi, I have a question about nat functionality.
The problem is that I opened a port to access my private network. I put a
server to listen on port 10000 and then I get my public ip address (using a
service such as whatismyip.com) The problem is that when I telnet to this
public ip and port, the server in my machine doesn't get anything, but if I
try this from "outside", then the server receives the conection! How can
this be? Why putting the public ip inside my private network doesn't work?
Shouldn't this be treated as any other conection? (Of course, if I connect
to the loopback or private ip, the server receives ok)

Thanks i nadvance.

In article <dv1bgh$15l$1@nsnmpen3-gest.nuria.telefonica-data.net>,
dan <x@x.com> wrote:
>Hi, I have a question about nat functionality.
>The problem is that I opened a port to access my private network. I put a
>server to listen on port 10000 and then I get my public ip address (using a
>service such as whatismyip.com) The problem is that when I telnet to this
>public ip and port, the server in my machine doesn't get anything, but if I
>try this from "outside", then the server receives the conection! How can
>this be? Why putting the public ip inside my private network doesn't work?
>Shouldn't this be treated as any other conection? (Of course, if I connect
>to the loopback or private ip, the server receives ok)

You have not indicated which equipment you are using.

For example, the Cisco PIX running software up to 6.x, is specifically
designed to prevent packets that enter through one interface
from going out the same interface. This was deliberate, to prevent
people from violating policy by deliberately bouncing their packets
off of the PIX.

In article <dv1bgh$15l$1@nsnmpen3-gest.nuria.telefonica-data.net>,
"dan" <x@x.com> wrote:

> Hi, I have a question about nat functionality.
> The problem is that I opened a port to access my private network. I put a
> server to listen on port 10000 and then I get my public ip address (using a
> service such as whatismyip.com) The problem is that when I telnet to this
> public ip and port, the server in my machine doesn't get anything, but if I
> try this from "outside", then the server receives the conection! How can
> this be? Why putting the public ip inside my private network doesn't work?
> Shouldn't this be treated as any other conection? (Of course, if I connect
> to the loopback or private ip, the server receives ok)

Most NAT routers only recognize the public IP when they receive packets
on the outside. When you're on your LAN, you have to use the private IP.

There are some routers that will forward the public IP on either side,
I've heard that D-Link does.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

>> Hi, I have a question about nat functionality.
>> The problem is that I opened a port to access my private network. I put a
>> server to listen on port 10000 and then I get my public ip address (using
>> a
>> service such as whatismyip.com) The problem is that when I telnet to this
>> public ip and port, the server in my machine doesn't get anything, but if
>> I
>> try this from "outside", then the server receives the conection! How can
>> this be? Why putting the public ip inside my private network doesn't
>> work?
>> Shouldn't this be treated as any other conection? (Of course, if I
>> connect
>> to the loopback or private ip, the server receives ok)
>
> Most NAT routers only recognize the public IP when they receive packets
> on the outside. When you're on your LAN, you have to use the private IP.
>
> There are some routers that will forward the public IP on either side,
> I've heard that D-Link does.

Hi, thanks both for your answers. The router I use is a ziyxel which seems
to be a bit weird.
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? Or does the nat somehow realizes that I'm
trying to simulate a conection from the outside? If that weren't the case,
then I presume the packet is received by some outside router which sends it
back to the nat again, is this correct?
I'm certainly missing something, because I don't see why shouldn't the
packet be received by the nat, given that the dst port is opened.
I appreciate in advnace any .

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.)

> In what part does the packet get lost?

In general nat devices only translate traffic traversing the wan
interface. Traffic destined for the wan interface address from the lan
never traverses the wan interface and therefore is never translated. The
router is the final destination for such traffic.

A working example would be to configure port forwarding to a web server
and then try to access the web server from the lan using the public
address. You'll see the router web interface instead of the web server.

The solution is to use private addresses from inside the lan. Configure
the hosts file or implement a dns server if you would like name resolution.