IPFW/NATD Transparent Proxy

[Incoming Mail List]

>Your ipfw rules are invalid.

They seem to work perfectly.  My only gripe is that static rule
#15100 is required to succeed with redirect_port from 1.2.3.4:80 to 
192.168.2.250:80 when 192.168.1.247 requests a web page using the domain
name for 1.2.3.4.  I'm looking for a solution that doesn't require rule
#15100.

>This causes the dynamic
>internal state table to cross match packets in error because it does
>not keep track of which interface the packet is from. This has been
>a long time bug in stateful rules for NATed interfaces. Technically
>your whole stateful environment is being forced to look like its
>working when in fact its all most useless.

How can that be?  If I'm on 192.168.2.100, I can make a request to
www.cnn.com and it works fine.  Yet I have no rule that allows any
packets to be accepted IN via my outside nic (de0), and no rule that
allows any port 80 OUT to my private lan on de2.  That sounds to me
like the dynamic rules are working.  How else are the packets getting
into de0 and out to de2?

>That is why the stateful + nated rule example from the new firewall
>rewrite uses skipto rules to work around this problem.

I'm using skipto's as well, just not using the keep-state parameter
on the skipto rule.  I don't believe the transparent proxy problem
I'm having is a result of skipto.  It's a chicken/egg issue when 
using stateful rules because either NATD or the original nic "remembers"
that the packet changed when it got redirected.

If I allow the stateful rule first, it gets created as
        192.168.1.247 <-> 1.2.3.4
and immediately starts communicating with the outside interface due
to the dynamic rule bypassing the rest of the firewall.  So the
packets never get to go through the divert rule to be redirected
to 192.168.2.250.

If I go through divert first (as in my firewall example), the packet
matches rule 100, the destination gets changed to 192.168.2.250, and
the packet continues down through the firewall.  Great!  Next, it
matches on 300 and gets passed to 15000 where a the dynamic rule
192.168.1.247 <-> 192.168.2.250 gets created.  More greatness!  When
192.168.2.250 replies to 192.168.1.247, that packet also matches rule
100, gets diverted and NATD rewrites the source to the original IP
address so the packet is now configured as 1.2.3.4 -> 192.168.1.247.
Continued greatness!  But now, the packet gets denied at 15200 (remember
15100 does not exist in this example) because there's no rule to allow
1.2.3.4 to communicate with 192.168.1.247.  Hence, I have to add in
#15100 to explicitly allow 1.2.3.4 to communicate with 192.168.1.247.
In my example ruleset I simply allowed anything to go out via de1.


>Basically the unpublished rule of thumb
>is ipfw keep-state rules can not be used on the internal interface
>and external interface in same rule set. Keep-state rules can only
>be used on the external interface. There are no error messages to
>enforce this.

Actually, the only problem I've run into is the combination of
external/internal with NATD doing a redirect_port or redirect_address.
I've not run into any problems with external/internal and normal NATD
address translations.


J



IPFW RULES
==================================
00100 divert 9000 log ip from any to any
00200 allow log ip from any to any out via de0 keep-state
00300 skipto 15000 log ip from any to any via de1
00400 skipto 20000 log ip from any to any via de2
00500 deny log ip from any to any
15000 allow log ip from any to any in via de1 keep-state
15100 allow log ip from any to any out via de1
15200 deny log ip from any to any
20000 allow log ip from any to any in via de2 keep-state
20100 allow log ip from any to any dst-port 80 out via de2
keep-state
20200 deny log ip from any to any
20300 deny log ip from any to any


NATD Config File (/etc/natd.conf)
redirect_port tcp 192.168.2.250:80 1.2.3.4:80

NATD Command
/sbin/natd -dynamic -n de0 -p 9000 -f /etc/natd.conf