RE: [GD-Windows] ADSL firewall networking problems

[Jon W. <hp...@mi...>]

> What kind of firewalling/NAT/proxies are typical with ADSL
> providers? ADSL is not offered in our corner of Europe
> and thus it caught us entirely by surprise.

Many ADSL set-ups use NAT. Problems with NAT come when you 
need to send packets "in" to the user, who are not "replies" 
to packets going "out" from the user. This may be information 
you already know, but it bears repeating:

If you have this situation:

Server <---> NAT <---> User

NAT is the gateway for the User. The User creates and binds 
a socket, which gets a local port number Pu on the User machine 
with address Au. He then uses this socket to sendto() some 
remote port number Ps.

NAT will re-write the "source" address/port field to some 
NAT-local port Pn, and using the external NAT gateway address 
An. NAT remembers the tuple Pn->Au/Pu.

The Server gets a packet, and looks at the recvfrom() address 
to figure out the return address: the server sees An/Pn. 
Server figures out what data to send to the User, and sends it 
back to An/Pn.

NAT box sees a packet arriving at Pn, and looks up Pn in his 
translation table. If found, he forwards it to Au/Pu, re-writing 
the "destination" header, and the User sees the packet as if 
nothing had happened.


The problem comes if you send or use IP addresses or ports that 
are not part of the headers that get correctly re-written by 
NAT. If you have a field in your packet that says "IP address" 
or "IP port", then your protocol is fundamentally broken from 
the point of view of NAT. Some famous fundamentally broken 
protocols include FTP and H.320, so you'd be in good company :-) 
Part of NAT friendly protocol design is to only use the addresses 
as seen by sendto() and recvfrom(), and not put addressing data 
in your data packet.

If you're using peer-to-peer networking, it gets even more 
exciting, because some "server" may tell a "user" about some 
other "user" he's supposed to communicate to. This counts as 
"IP/port" data which is part of your packet, and thus won't get 
properly re-written by NAT.

As you can see, nobody who "listens" for "remote" connections, as 
opposed to "initiating" them, can sit behind NAT, unless you make 
the NAT explicitly aware of this port and forwards the port 
traffic to some specific listener inside the translated network.

If you're trying to get peer-to-peer working when both peers are 
behind one NAT box each, and the NAT boxes don't support custom 
port forwarding (or the users don't set it up) you're never going 
to get it to work, unless you use some external third server 
which sends what amounts to properly forged packets to introduce 
the two sites to each other. Most hosting/service providers don't 
take kindly to you doing IP forgery, so I'd be hesitant to base a 
business on being able to do that.


Cheers,

			/ h+