>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 18.104.22.168:80 to 192.168.2.250:80 when 192.168.1.247 requests a web page using the domain name for 22.214.171.124. 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 <-> 126.96.36.199 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 188.8.131.52 -> 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 184.108.40.206 to communicate with 192.168.1.247. Hence, I have to add in #15100 to explicitly allow 220.127.116.11 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 18.104.22.168:80 NATD Command /sbin/natd -dynamic -n de0 -p 9000 -f /etc/natd.conf _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"