Date: Mon, 10 Jul 2006 12:10:14 +1000 From: Michael Vince <mv@thebeastie.org> To: freebsd-pf@freebsd.org Subject: PF firewall rules Message-ID: <44B1B706.2030406@thebeastie.org>
next in thread | raw e-mail | index | archive | help
Hi all,
I have some questions about pf rules, and just want to get some things
clear in my mind about how PF works, no doubt some of the answers will
be obvious to some.
I wanted to create some pf rules for TCP that can withstand loosing
state but still utilizing the advantage of single line firewall rules.
I might remove these in the future but just want to at least do some
testing on a firewall setup for many reasons such as it has 2 separate
links and want to try changing between the links/routes without
affecting state.
Take this rule for example
pass out on fxp0 proto { tcp, udp, icmp } from any to any modulate state.
What TCP flags rules are being used when you use "modulate state" for
the TCP protocol? is it the same kind of rules as UDP as in as it
largely ignores flags (as UDP has none) and if any TCP packets are going
out then it just tracks that state? or is it working on the most popular
Flags option rule such as "flags S/SA"
If its just any flag this would mean I could just /etc/rc.d/pf restart
(over resync) on the firewall gateway and the users aren't likely to
notice anything as the TCP protocol would probably just resend its last
sent packet believing the last one was dropped.
I haven't tested but I would assume if some one was playing a UDP based
game like counter-strike I could do pf restarts and they would probably
not notice or have just a little pause in the game since it would only
take a split second for the client side of the game to send out a UDP
packet reinstating the UDP outgoing state rule, so this should be easy
enough to do on TCP with lean flags (if modulate state doesn't do it).
I was thinking a minimal interference keep state firewall rule would be
based on any flags going out except for the R (reset) flag, is this correct?
Also when I used to use IPfilter you could place firewall rules on the
external interface for internal NAT IPs, I would use this to filter
packets for internal IPs but place the rules on the external interface.
pass out on $ext_if proto { tcp, udp, icmp } from 192.168.1.5 to any
modulate state.
Unlike IPFilter these rules never work with PF and it appears that any
rules creating for the $ext_if interface are ignored.
As I understand it translation occurs /before/ filtering, if I have NAT
set on my external interface, internal IP packet filter rules on the
external interface never work since the external interface Never saw any
internal IPs reach it, is the correct way to see it?
Given that if I used the example firewall rule listed at the bottom on
this URL with NAT. http://www.openbsd.org/faq/pf/filter.html
What is the recommended way to place restrictive rules on internal IPs?
does any one have some examples as there are none on the OpenBSD PF guide.
To me it just fits better inside my head to place these rules on the
external interface in a keep state manner, while having stateless rules
on the internal IPs interface just as this example ruleset has done on
that web site.
pass in on $int_if from $lan_net to any
pass out on $int_if from any to $lan_net
Thank you,
Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44B1B706.2030406>