> 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+
|
