Re: OT: Port forwarding technologies
Re: OT: Port forwarding technologies
- Subject: Re: OT: Port forwarding technologies
- From: "Matt Slot" <email@hidden>
- Date: Fri, 8 Sep 2006 13:56:24 -0400
Mark Thomas (email@hidden) wrote:
> I was wondering apart from NAT-PMP and UPnP technologies/standards are
>there any other sort out there ?
Another one people overlook is SOCKS. While originally designed to open
ports in firewalls, a SOCKS server also lets you create a listener port
outside a troublesome NAT. I'm not sure how many people use SOCKS these
days, but the protocol is straightforward enough, it has authentication,
and it doesn't require the router to know anything about it.
>if I only support the NAT-PMP & UPnP
>does any body know what sort of router coverage this would give 80-90% ?
In addition to the router handshake support, you can get good coverage
with an Internet matchmaker server. Many NATs can be negotiated by a
simple handshake with the connecting client, and you can detect those
that can't and at least provide a friendly warning or error message.
I've written a handful of documents on the topic:
http://www.codewhore.com/nat3.html
http://www.codewhore.com/nat4.html
http://www.codewhore.com/nat5.html
Our software doesn't support UPnP (see below) or proxy servers, but it
does support PMP and the NAT coping techniques documented above. It's my
experience that this works for about 90% of the NAT devices out there
(although we tend to be a bit Mac-centric).
Also, a bit of warning: some routers will capriciously change the public
port of an established mapping for no apparent reason. One case (older
Airport base stations) is addressed by setting TTL=2 for the packet that
creates a local mapping. Still, the matchmaker server, your server, and
any clients must to watch for sudden changes in the source address of
incoming packets. I suggest a sharing a unique identifier and maybe some
security token so that you can recover seamlessly. These are the edge
cases that will cause you headaches and teach you to hate NAT.
> Also one issue with using this is that the setting expire where I would
>like to them to be preserved as I'm trying to automate a device setup which
>needs a port to forwarded to it for configuration capabilities.
PMP supports short timeouts and works well. Some UPnP devices on the
other hand only support a permanent lease, which your application must
close when quitting or risk security headaches. Due to this and several
open issues against our UPnP support, we've decided to leave it out of
our imminent releases.
/* Matt Slot, Bitwise Operator * <http://www.ambrosiasw.com/~fprefect/> */
/* "I never let schooling interfere with my education." -- Mark Twain */
_______________________________________________
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