Traffic mysteriously dropping
Christopher McGee
chris at xecu.net
Fri Mar 31 23:38:21 UTC 2006
Greg Hennessy wrote:
>>The first rule is block log all. I put the http rules right
>>after that rule, or I lose connections.
>>
>>
>
>I would suggest minimising the amount of non stateful rules in the policy.
>They have a habit of biting one in the rear.
>
>
>
There are only 3 or 4 rules in the ruleset that are non-stateful. I can
try to eliminate those also.
>>The packets are not being logged as
>>blocked.
>>
>>
>
>A block further down the policy without a 'log' may cause this.
>
>One of the joys of debugging a last match policy.
>
>
>
All rules that are block are also using log. A lot of the pass rules do
not because it generates such enormous logs. I can try enable logging
on every rule temporarily in order to troubleshoot this if necessary.
>>The just never show up on the internal nic.
>>
>>
>
>I take it you've simultaneously tcpdumped both ingress and egress interfaces
>to confirm this ? Packets disappearing during traversal implies a routing
>issue.
>
>
>
Yes, if I tcpdump on em0, pflog0, and em1 simultaneously during a
traffic test, the traffic hits em0, and never shows up as blocked in
pflog0 and never shows up at all on em1. As I stated, it's only 1 out
of a bunch of connections, so there is no rule blocking all the traffic.
>
>
>>I can make this a bi-direction rule instead of keep state
>>
>>
>
>That's inefficient as each packet forces a rule base traversal.
>
>Try coding a tcp flow as
>
>pass log quick on em inet proto tcp from source to dest port something keep
>state flags S/SA
>
>
>I said 'em' above, not em[0-9].
>
>Using interface groups without directionality, means that a single rule will
>match the flow on both the ingress and egress interfaces.
>
>Combined with antispoof, it makes for simpler policy
>
>
>
I have coded the rule as explained above and even as the first rule
after the default block rule, it still drops traffic. If I change it to
non-stateful, it doesn't drop the connections. I can't seem to get away
from the thought of a state mis-match, however, I don't know why it
would consistently do it on these http connections.
>>and it still drops traffic if I
>>move it down in the list. If I leave it where it is, and
>>make it a keep state rule, it drops the connections also.
>>
>>
>
>What other blocks are in the policy ?
>
>
>
I don't believe I'm doing any specifc blocks. Just the default block
and then allow what we need after that.
>>At peak times, the state table grows as large as 17000 states
>>or so.
>>
>>
>
>If that's the case, the default table size is inadequate, I would set it to
>at least 25000.
>
>
>
I bumped up the state limit a long time ago. I haven't run into issues
with that. There is adequate room in the state table even during peak
times. Unfortunately, it's dropping the traffic even during slow times.
>>Generic egress rules are a little difficult because I'm trying to do
>>traffic shaping of certain traffic.
>>
>>
>
>Get the policy working without drops 1st, then shape.
>
>
>
Agreed, altq has been disabled until I can get the traffic flowing smoothly.
>>A side note, the machine is not doing any NAT. Tagging seems like it
>>
>>
>would require more
>
>
>>overhead than what the firewall is doing already.
>>
>>
>
>It doesn't. Tagging works per stateful flow, not per packet. Using tagging
>will permit you to significantly reduce the size of the rulebase.
>
>
>
The ruleset will be getting a significant rewrite, however, time has not
permitted it yet.
Chris
More information about the freebsd-pf
mailing list