Date: Tue, 11 Jul 2006 15:40:38 +1000 From: Michael Vince <mv@thebeastie.org> To: Dmitry Andrianov <dimas@dataart.com> Cc: freebsd-pf@freebsd.org Subject: Re: PF firewall rules Message-ID: <44B339D6.7090401@thebeastie.org> In-Reply-To: <D5972F49810A69449A9EA72A4B360DC2D0A38F@e1.universe.dart.spb> References: <D5972F49810A69449A9EA72A4B360DC2D0A38F@e1.universe.dart.spb>
next in thread | previous in thread | raw e-mail | index | archive | help
Dmitry Andrianov wrote:
>Hello.
>
>
>
>>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.
>>
>>
>
>I'm not sure how this should work. If you change outgoing NAT address
>(what else "switching the link means"?), everything WILL break. With
>both UDP and TCP any stateful firewall on server side will reject
>"stream" where address changes in the middle. Even if there is no
>stateful firewall on their side, TCP implementation on the server will
>not accept these packets.
>
>
>
>>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"
>>
>>
>
>AFAIK, it does not check flags.
>
>
That still doesn't really answer my question and I also am looking for a
flags example of what would guarantee to provide the desired behavior.
>
>
>>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.
>>
>>
>
>Yes, if you restart pf with such a rules, the next _outgoing_ packet
>(what has a rule in your firewall) should restore the state. But keep in
>mind that a packet in opposite direction will not restore the state
>(because it has no separate rule for it and used to match on state
>only). So such a packet will be blocked.
>
>Btw, I'm not sure why you need restarting pf at all. If you need it to
>reload the rules, use
>
>pf -F rules -f /etc/rc.pf
>
>It will flush all rules and load new from file while keeping all the
>states.
>
>
As I said above I am testing, I said restart over any kind of resync,
Its far easier and less error prone to just use the built in
"/etc/rc.d/pf resync" command to keep state while loading in new rules,
compared to typing all that out manually.
pf_resync()
{
$pf_program -f "$pf_rules" $pf_flags
}
>
>
>>What is the recommended way to place restrictive rules on
>>internal IPs?
>>
>>
>
>Why can't you filter incoming packets as they come on internal
>interface? IMHO it is more natural because you stop unwanted traffic
>early..
>
>
So your saying that to stop packets going *out* its more "natural" to
type up a *block in* firewall rule to achieve the desired result, I
think its is a hard point of view to argue, and this was something that
was never needed with IPFilter and is probably one of its better
remaining features over PF.
So to block to block IP 192.168.1.17 from connecting *out* to anything
on the internet I have to use a "block in" statement and there is no
other way of doing this rule?
block in quick on $int_if proto { tcp, udp, icmp } from 192.168.1.17 to any
Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44B339D6.7090401>