[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: using the ! ('not') modifier



On Wed, 27 Oct 2004 10:28:52 +0200 (CEST), Björn Ketelaars wrote:
>> If you don't want any PCs on the LAN to access your server but for udp
>> 53 (will mean you can't even SSH into the box) why don't you add
>> something like:
>>
>>   pass in quick on $int_if proto udp from $int_if:network to $int_if \
>>     port $int_udp keep state
>>   block in quick on $int_if from any to $firewall_internal_ip
>>
>> Surely that is a better solution?
>>
>> Andrew
>
>
>Hello,
>
>Thanks for your reaction!
>
>I guess your solution is more efficient, but that is not the problem. What
>I want is the following:
>
>Block all
>Pass in on $int_if from $int_if:network to any keep state
>Block in on $int_if from $int_if:network to { $int_if:network,
>$int_if2_other:network }
>Pass in on $int_if proto udp from $int_if:network to $int_if port = domain
>keep state
>
>This makes it possible for a package to reach the internet and make
>DNS-queries on the internal firewall ip ($int_if). These rules also
>provide in blocking traffic to $int_if2_other:network. This works like a
>charm.
>Now I thought to be clever by using the ónotó-modifier (!) so the above
>rules would look like:
>
>Block all
ass in on $int_if from $int>P_if:network to !{ $int_if:network,
>$int_if2_other:network } keep state
>Pass in on $int_if proto udp from $int_if:network to $int_if port = domain
>keep state
>
>The first rule should provide in passing all traffic except to the server
>($int_if) and a secondary range. The second rule opens UDP port 53.
>Unfortunately this doesnºt work. It seems as if the ónotó modifier does
>not do what I believe it should do.
>
>Regards Björn
>
I see one thing sticking out like male dog's gonads  there:
Pass in on $int_if from $int_if:network to !{
$int_if:network,$int_if2_other:network } keep state
Unless it is the late hour here getting me (2210 after waking at 0430)
it seems that there is no point in trying a double negative there. All
traffic from $int_if:network to $int_if:network doesn't need to be
blocked on its  interface because it never will pass through that
interface. By definition it is on its own LAN already as are the
recipients. So no routing will happen via that interface for that
network.
Now your rule simplifies to:
Pass in on $int_if from $int_if:network to !{$int_if2_other:network }
keep state
and you are clear of the logical ambiguity.
Think of this:
pass from x to ! { x , y}
Do you intend the comma to mean AND or OR ? (or maybe neither?)
I am not sure what you wanted is indicated by your proposed rules.
>From the land "down under": Australia.
Do we look <umop apisdn> from up over?
Do NOT CC me - I am subscribed to the list.
Replies to the sender address will fail except from the list-server.