Thanks again for coming back with more comments Kajetan.
> Cool. I know the states are different (due to direction differences) but I
> > was wondering if
> > there was a way around that to save on the number of states and somehow
> get
> > away with
> > only 1 state. So now I understand having two states per connection is
> fine.
>
> Why shouldn't it be? Searching through states is quite fast. Even with
> hundreds
> of thousands of states much faster than going through a few hundreds of
> rules,
> from my experience.
Yeah, only the number of states was my concern. On a related note what is
the maximum
number of states that you have been able to sustain and in what amount of
memory?
I know it's pretty low memory overhead but still. In other words how much
memory
per state is being consumed by PF? Currently I am prepared to start with
200K states
and the router has 24GB or RAM. What is a reasonable maximum that I can
expect to be able to handle?
I am monitoring closely (nagios + graphite) those states as well btw.
> > *Is there any security risk in me allowing the traffic pass the external
> > interface and then dropping it on the internal interface?*
>
> That depends if the traffic from the Internet can hit the router's IP stack
> directly. For example if you assign public IPs of servers in VLANs to the
> router's $ext_if and use nat or route-to to forward traffic to VLANs.
> Whatever
> does not hit those rules but is passed on $ext_if, will hit the router
> itself
> in such case.
Yes, that's a good point! I should have mentioned that the first few rules
take
care of traffic going to the router itself and end with block quick from
any to <me>
where <me> is a constant table of {self}. No NAT.
So I guess it was just an irrational fear that I wanted to make sure it's
only me
that having let the packet "half-way in" through the external interface is
OK as
long as I filter it on the internal/vlan interface. No further implications
aside from
traffic destined to the firewall itself. Correct ?
Thanks for all your comments,
--
Rumen Telbizov
Unix Systems Administrator <http://telbizov.com>
_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
