[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-pf
Subject:    Re: Newbie Question (one of many to come)
From:       Daniel Hartmeier <daniel () benzedrine ! cx>
Date:       2002-08-13 9:59:18
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]