On Mon, Aug 12, 2002 at 03:27:35PM -0700, Chris Willis wrote: > I did not want to discuss the particular application, as it was developed > by an outside vendor for us to use. It is a confidential app. > > Besides, the application is not of consequence.
It matters whether the protocol embeds client IP addresses inside the data stream. There are many such protocols that don't survive NAT at all. If you don't know or can't tell, try the procedure I suggested to find out. > The logistical problems don't seem that big of a deal. If the server > records that 192.168.100.100 sends out tcp 5000 packets to 20.20.20.20, > then it should have no problem knowing that udp 4900-1 should go back to > 192.168.100.100. Heck, it probably isn't even much extra code. In case of instant messaging clients and online games, there will be multiple concurrent connections, and the problem is forwarding the back-channels to the right local client. The firewall gets an incoming UDP packet to port 4900. It checks the state table and sees the following established TCP connections: 192.168.100.100:60001 -> $ext_if:55001 -> 20.20.20.20:5000 192.168.100.101:60001 -> $ext_if:55002 -> 20.20.20.20:5000 192.168.100.200:61234 -> $ext_if:55003 -> 20.20.20.20:5000 Where should the incoming UDP packet be forwarded to? .100, .101 or .200? If you're claiming general usefulness for a broad range of protocols, you have to address this case. Daniel
