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
