more IPFW help please

[Saint Aardvark the Carpeted]

Incoming Mail List disturbed my sleep to write:
> NATD definition
> natd -p 8668 -redirect_port tcp 192.168.2.254:80 80 -n de3
> 
> IPFW definitions
> 100 divert 8668 log ip from 192.168.3.254 to 1.2.3.4
> 300 allow log ip from any to any
> 500 deny log ip from any to any

I *think* the problem with this set of rules is that you're diverting to
natd anything from the private client to the webserver, *but you're not
diverting the replies from the webserver*.  Your request goes to the
webserver with the source address set to 192.168.3.1 (the IP address
on de3).  The webserver sends the reply to 192.168.3.1, but since that
reply never gets to natd, 192.168.3.1 "knows" it didn't send that request
so it gets dropped silently.

One way around this would be to add a second rule:

	200 divert 8668 log ip from any to 192.168.3.254

but that may cause problems...natd may drop incoming connections or
replies that it hasn't seen.  Since natd is only seeing requests to
1.2.3.4, access to other machines may end up broken.

A better/more conventional way of doing it would be:

	100 divert 8668 all via de3

> This results in lots of packets accepted, but I get no output on the
> 192.168.3.254 machine and the browser eventually times out.
> 
> 100 Divert 8669 TCP 192.168.3.254:4013 24.61.225.235:80 in via de3
> 300 Accept TCP 192.168.3.254:4013 192.168.2.254:80 in via de3
> 300 Accept TCP 192.168.3.254:4013 192.168.2.254:80 out via de2
> 300 Accept TCP 192.168.2.254:80 192.168.3.254:4013 in via de2
> 300 Accept TCP 192.168.2.254:80 192.168.3.254:4013 out via de3

Logs are good, but tcpdump is better -- you get to see the tcp flags.
This looks good, which is why I'm hedging my bet about the divert rules,
but tcpdump on (say) your client, or the machine running natd, would
show a lot more. 

HTH,
Hugh
-- 
Saint Aardvark the Carpeted
aardvark at saintaardvarkthecarpeted.com
Because the plural of Anecdote is Myth.