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: <<A HREF="http://www.nealis.net/ascend/faq">http://www.nealis.net/ascend/faq</A>> </PRE> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <!--X-Follow-Ups-End--> <!--X-References--> <HR> <STRONG>References</STRONG>: <UL> <LI><STRONG><A HREF="msg10350.html">Re: (ASCEND) Quake/QW and Pipeline 75 and NAT</A></STRONG></LI> <UL> <LI><EM>From</EM>: James Johnson <plexus@plexus.seanet.com></LI> </UL> </UL> <!--X-References-End--> <!--X-BotPNI--> <HR> <UL> <LI>Prev by Date: <STRONG><A HREF="msg10354.html">Re: (ASCEND) 5.0Ap33 results here...</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg10352.html">(ASCEND) 5.0Ap33 results here...</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg10350.html">Re: (ASCEND) Quake/QW and Pipeline 75 and NAT</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg10351.html">Re: (ASCEND) Quake/QW and Pipeline 75 and NAT</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="maillist.html#10353"><STRONG>Main</STRONG></A></LI> <LI><A HREF="thrd226.html#10353"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> </BODY> </HTML>