[Bug #133374] bzfs assumes client UDP port is same as server

[<no...@so...>]

Bug #133374, was updated on 2001-Feb-20 21:53
Here is a current snapshot of the bug.

Project: BZFlag
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: timriker
Assigned to : bzfrank
Summary: bzfs assumes client UDP port is same as server

Details: This breaks many NAT firewalls. The server should listen on a port
and reply to whatever port the client packets come from.

Follow-Ups:

Date: 2001-Feb-21 10:24
By: nobody

Comment:
Some NAT router does something different. They need to be told what client
to forward UDP packets. (e.g. Zyxel ISDN routers)

See my other posting about the multiple port. Beside I suggest not to
discuss such things as "bug" - really this is more a theme for the plain
dev mailing list. I opt to keep the bug tracking for true bugs only and not
feature requests.

- bzfrank

-------------------------------------------------------

Date: 2001-Feb-21 09:43
By: timriker

Comment:
When running behind a ip masquerade style firewall as is contained in many
DSL and cable modem routers, the outgoing port number is remapped by the
router to a night numbers address. This is a first available type solution
as multiple systems behind the fw could all request the same outgoing port.
so 192.168.87.4:17200 -> serv:17200 becomes:

192.168.87.4:17200 ->fw:64300 -> serv:17200

the server only sees the address of the fw and _must_ use the port address
the fw assigned in order to be able to get packets back:

serv:17200 -> fw:64300 -> 192.168.87.4:17200

the fw keeps a table of port translations for the return trip packets.
-------------------------------------------------------

Date: 2001-Feb-21 07:07
By: nobody

Comment:
Can you elaborate this? Right now the client sends always to the port given
by the server in its MsgUDPLinkGranted and sends to the port given in
MsgUDPLinkRequested, this is usually 17200-17220 for the receive port in
the server as each client gets a unique port and 17200 in most cases in the
client. Therefore the first player should already get this configuration
right now (17200 <-> 17200), however it does not help for the NAT routers I
tested on.

(bzfrank - posting as nobody because cookies are not enabled)

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133374&group_id=3248