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
_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
