Thanks for your answer and comments Kajetan. See my comments below.
> The question is: Is keeping two states for one connection a bad thing or > is > > it an acceptable practice ? > > It's rather a requirement. A packet incoming on one interface creates a > different state than the same packet outgoing on other interface (even > without > if-bound state policy). And you want further, reverse direction packets in > connections to be matched to existing states and passed instead of > traversing > rule list or hitting the block rule. 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. > If you want to fully ignore the interface, you can use "set skip" for that > purpose. Although I'm not sure if NAT will work in such case, should you > need > it. It also would be nice to set skip on the loopback interface. > > > pass quick on $ext_if no state > > This rule passes the traffic both directions, so it's probably fine. > Although > using stateful inspection would increase security a bit. The reason I didn't go on a complete skip on $ext_if is that I actually do have a handful of rules on the external interface just before that one. Things like blocking from bad hosts, etc. Very few though. I do skip on loopback. I went with the 'no state' since this was my 'hack' to reduce the number of states to only 1 on connections traversing the external interface. In fact this is partially what provoked my question on saving on the number of states between vlans. But I simply cannot figure out a way. I was more curious to know what you and other folks think regarding my first question: *Is there any security risk in me allowing the traffic pass the external interface and then dropping it on the internal interface?* Thank you very much, -- 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"
