Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Quake/QW and Pipeline 75 and NAT
Sir,
Apparently, your knowledge of UDP/TCP is lacking. Maybe this will
help... if not, try reading some RFCs.
One thing you have to keep in mind is that there are many UDP and TCP
protocols in use that work with single ip address NAT. Another thing to
keep in mind is there are 2 ports and 2 ip addresses that describe a
TCP/UDP session. Have you ever wondered how DNS, HTTP, and telnet
packets manage to work through single ip address NAT? Yes, the pipeline
mangles a port address, but you have to remember that it only changes
the source ip address and the source port number. It does not change
the destination IP address or port number (for outgoing packets). For
incoming packets, it changes the destination IP address and port number
via a translation table it created when the client sent out its first
packet for the connection in question. This is why (without static
maps) nobody can "get in" your machines from the outside, but also why
packets belonging to a current UDP/TCP session started by the client are
magically able to get through.
To summarize, a UDP or TCP session identifier is actually made up of the
client's IP address and port number, AND the server's IP address and
port number. If quake simply looked at the packet headers it received,
(the pipeline very nicely does not disturb the server's port address and
IP address) it would be possible to play quake through NAT. (or any
other proxy software, for that matter). Apparently, from what you're
saying, Quake does read the client's IP address from the packets, but
unfortunately, does not take the client's port address from the UDP
header... it actually asks the client what it's port address is... of
course for single IP address NAT, this fails miserably.
A simple example follows:
Quake server: 99.88.77.66
Quake client (fake): 192.168.10.10
Quake client (real): 208.98.76.54
1. Client sends a packet with UDP id: 99.88.77.66:26000,
192.168.10.10:1234.
2. Pipeline mangles the header to be: 99.88.77.66:26000,
208.98.76.54:5678.
3. Quake server receives above packet. Notes that the client's ip
address is 208.98.76.54. The client encodes it's source port (1234) in
the UDP DATA area (not the header... the UDP header correctly reads
5678). This is probably some artifact that came from Quake's IPX
engine???
4. Anyway, Quake server sends packet with UDP id: 208.98.76.54:1234,
99.88.77.66:26000. The pipeline receives a packet, and the only thing
in it's tables is the fact that 208.98.76.54:5678 maps to
192.168.10.10:1234. The pipeline doesn't know what to do with a packet
with UDP destination port 5678, and discards he packet.
This can be verified by sniffing the client and server packets, or by
simple deductive reasoning:
1. There are only 2 machines which are aware of the original client port
address: the client and the Pipeline. How did the server get hold of
the original client source port number? The Pipeline didn't tell the
Quake server... the client must have encoded it in the UDP data area.
2. There isn't an "agreed upon" source port number. Try typing "status"
during a quake game at the quake command line.
Basically, it boils down to this:
If Quake does not look at the UDP header to figure out what the client's
port is, (in other words, Quake effectively asks the client what it is),
id did not follow the UDP standard. If there is a "standard" client
port (which I doubt severely), id again is not following the UDP
standard.
This has been a _long_ acknowledged problem with Quake's UDP (and I use
the term loosely) protocol. I'm sure there are pleanty of people on
usenet you can speak to about it.
James Johnson wrote:
>
> Um did you read all of my posting? There is no information in the datagram
> pertaining to a port # other than the udp port. If I send a packet from any
> machine with a specific port destionation to a Pipeline (doing Single IP
> NAT) the port # gets mangled.
Remember, there are 2 16-bit port numbers. The Ascend boxes will not
touch the server's port number. The pipeline only mangles the client's
port number, which is OK.
> This is perfectly fine. Everyone knows that unless you tell the Pipeline to
> do a specific mapping for that port this will happen. This is what NAT
> does. Perfectly normal.
You've got it backwards here... static mappings are for clients
_outside_ of your lan to access servers _on_ your lan. This doesn't
apply to the problem you're having.
> Its not a problem with Quake, its not a problem with the Pipeline. It just
> the way NAT works.
It's a problem with Quake's implimentation of UDP. This is why Quake
doesn't work, and other UDP/TCP-based protocols do.
> No the problem you face is not the IP, but the port # with Quake. The
> Pipeline uses the port # for translation purposes (as do all NAT
> implementations). This # gets mangled in the process. I observered, using
> NetXray, the port # which I sent out to the Quake server and the port #
> which came back. I'd be sending out 27k (or something close) and be getting
> back ports in the 4k range. Since Quake wasn't listening there the packet
> went un-heard, and into the bitbucket.
The Pipeline translates the source IP address and port number for
outgoing packets, and destination IP address and port number for
incoming packets. At no time will it change Quake's 26000 port to some
other port. Quake is simply not reading the translated client port the
Pipeline generated.
Go ahead and ask id Software why Quake doesn't work through Wingate,
Ascend's single ip address AT, or other single ip address proxy
software... if you don't believe anyone on this list.
Phew, that was long :)
Thanks,
--
Jason Eggleston
SysAdmin, Jet.Net Inc.
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>
References: