On Fri, Feb 15, 2002 at 06:09:51PM -0500, Michael R. Wayne wrote: [snip] > Using this ipfw rule on ProxyFirewall: > fwd $(squid-box) log tcp from $(windows-box) to any 80 > and checking the logs on ProxyFirewall, I see this horrible mess: > > ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 in via fxp1 > ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 out via fxp0 > <---!!! > ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 in via fxp1 > ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 out via fxp1 > ipfw: 60000 Deny ICMP:5.1 ProxyFirewall BROWSERbox out via fxp1 > ipfw: 60000 Deny ICMP:5.1 ProxyFirewall SQUIDbox out via fxp1 > last message repeated 31 times > > This, of course, causes terrible performance as the packets destined > for the local net bounce out the default interface. It can be > corrected by specifying an interface in the fwd rule: > fwd $(squid-box) log tcp from $(windows-box) to any 80 via fxp1 > > Is it expected behaviour for ipfw to disregard routing and put > packets out on interfaces where they have no chance of being properly > delivered (which would be odd) or is this a bug?
I believe you are misinterpretting the logs. Each of those log entries is saying, "At rule 11005 I am forwarding this packet to SQUIDbox. The packet that triggered this rule was TCP BROWSERbox:1631 216.136.204.21:80 that came (out of|into) to the firewall via interface (fxp0|fxp1)" That is, the 'via fxp?' at the end is telling you about the packet that _triggered_ the rule, not where the packet was actually forwared to. If you sniffed the connection, I expect that you would have seen four packets go from the firewall to SQUIDbox. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/ | [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message