Re: udp tunneling works but doesn't
Re: udp tunneling works but doesn't
- Subject: Re: udp tunneling works but doesn't
- From: "Peter Sichel" <email@hidden>
- Date: Mon, 14 Nov 2005 09:59:39 -0500
I'm just catching up on the list and noticed there was no response
to your question below.
On 11/1/05, email@hidden wrote:
> Now once I have my external IP and port, I try to
>send a packet to myself like so:
>
>192.168.0.5:10000 -> 4.3.2.1:54321 Hello
>
>And I never get the packet! What gives?
As a NAT developer, I've seen this many times. Many NAT implementations
do not provide "Local NAT" which allows hosts behind the NAT gateway
to access other private host using their public IP address. I've
implemented this feature in IPNetRouter, but it took some extra
work. Here's the typical NAT configuration:
Public Net --- NAT --- Gateway --- Private LAN
Outbound packets from your private LAN are relayed via the gateway and
then masqueraded by the NAT module to appear as if they came from the
gateways public address. If you try to access the gateways public IP
address from behind the LAN, the packets never pass through the NAT
function. With "Local NAT", the configuration changes to this:
Public Net --- NAT --- Gateway --- NAT --- Private LAN
I coined the term "Local NAT' to reflect that NAT is being performed on
both the Internet and LAN side of the gateway. Outbound packets from
the private LAN are NATed as if they had been received on the public
side of the gateway. This means if the destination IP address matches
the public IP of the gateway, it will be port mapped to the
corresponding private endpoint on your LAN. A second step is to
masquerade matching packets so they appear to have come from the public
IP of the gateway. When the server on your LAN responds, the response
is sent to the public IP of the gateway where the two translations
(source and destination IP endpoints) can be reversed.
It works beautifully. The other approach which some network
administrators use is to run a local caching name server on the gateway
itself to return the private IP address for hosts on your LAN when their
public domain name is requested.
> I am also unable to send
>from another computer, behind the NAT, to my computer's outside
>address. This seems incredibly stupid to block these packets, but
>it's the only conclusion I can come up with. I have run tcpdump and
>can verify that the packets are sent out by my computer but never
>come back.
These packets are not being blocked by the NAT function, but are
sometimes blocked by a packet filter. The idea is to prevent packets
that arrive on the public IP interface from claiming to be from your
private LAN (source address spoofing). The mistake here is that if the
packets really did arrive from the private side, they should be allowed.
From my perspective, this is why having a configurable NAT router is
still useful in this age of cheap Internet sharing boxes. IPNetRouterX
for example supports "transparent proxies" so you can map every web
request that originates from your LAN to a dedicated proxy server which
can authenticate the user (like those hotel Internet systems) or
restrict outside access to carefully chosen sites and protocols the
proxy server supports.
>FYI, my NAT tends to always map the internal and external ports to
>different numbers.
In my experience, this is undesirable. IPNetRouter always tries to use
the same port if it's available, or the next sequentially available port
to minimize the compatibility risk.
>Perhaps this is a pathetic attempt at security by the net architects,
>perhaps the NAT wants people to always send to the local IPs and
>ports if the packets originate from inside the NAT, I just dunno. I
>can't believe that it would be something that sinister, but the web
>never ceases to amaze me :-P Has anyone else seen this issue? If
>not, do you know of a generic networking newsgroup that I could ask?
>Thanx,
Implementing NAT is not an exact science, but includes some art based on
practical experience that is not universally shared.
- Peter Sichel
Sustainable Softworks
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden