freebsd-pf Digest, Vol 266, Issue 2
freebsd-p...@freebsd.org
freeb...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
or, via email, send a message with subject or body 'help' to
freebsd-p...@freebsd.org
You can reach the person managing the list at
freebsd-...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-pf digest..."
Today's Topics:
1. Re: return-icmp() relative question to ipf rule. (Remko Lodder)
2. Re: return-icmp() relative question to ipf rule. (jhell)
----------------------------------------------------------------------
Message: 1
Date: Mon, 26 Oct 2009 14:18:02 +0100
From: Remko Lodder <re...@elvandar.org>
Subject: Re: return-icmp() relative question to ipf rule.
To: jhell <jh...@DataIX.net>
Cc: freeb...@freebsd.org
Message-ID: <FDD45DEB-DF44-43BF...@elvandar.org>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
On Oct 10, 2009, at 4:09 AM, jhell wrote:
>
> I have a rule I used in ipfilter probably around 2 or so years ago
> and I am now getting around to trying to implement in it my pf
> rules. So far any results I have achieved have failed with no
> response back from the server and get dropped.
>
> The rule in ipf syntax:
> block return-icmp-as-dest(13) in log first quick proto icmp all icmp-
> type 8
>
> The above ipf rule returns a result of "Destination Administratively
> Prohibited" when ping'd
>
> The following pf syntax:
> block return-icmp(3,13) in quick inet proto icmp from any to any
> icmp-type 8 code 0
>
> The above pf rule returns a result of "Nothing ........" when ping'd
>
> Just to be sure I wasn't mucking up the chain of rules I added this
> as the only rule to test it out and have achieved the same result
> multiple times on a test machine.
>
> Can anyone shed some light on the syntax and help me out with
> getting this rule to make the system respond to a echo request with
> admin-prohib as the destination system ?
>
> Thanks
>
*click* (the light is on)
Options returning ICMP packets currently have no effect if
pf(4)
operates on a if_bridge(4), as the code to support this
feature has
not yet been implemented.
from the Manual page. I think that answers the question?
--
/"\ Best regards, | re...@FreeBSD.org
\ / Remko Lodder | remko@EFnet
X http://www.evilcoder.org/ |
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
------------------------------
Message: 2
Date: Mon, 26 Oct 2009 11:02:31 -0400
From: jhell <jh...@DataIX.net>
Subject: Re: return-icmp() relative question to ipf rule.
To: Remko Lodder <re...@elvandar.org>
Cc: freeb...@freebsd.org
Message-ID: <alpine.BSF.2.00.0...@qvzrafvba.5c.ybpny>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Mon, 26 Oct 2009 09:18, remko@ wrote:
> On Oct 10, 2009, at 4:09 AM, jhell wrote:
>
>>
>> I have a rule I used in ipfilter probably around 2 or so years ago and I am
>> now getting around to trying to implement in it my pf rules. So far any
>> results I have achieved have failed with no response back from the server
>> and get dropped.
>>
>> The rule in ipf syntax:
>> block return-icmp-as-dest(13) in log first quick proto icmp all icmp-type 8
>>
>> The above ipf rule returns a result of "Destination Administratively
>> Prohibited" when ping'd
>>
>> The following pf syntax:
>> block return-icmp(3,13) in quick inet proto icmp from any to any icmp-type
>> 8 code 0
>>
>> The above pf rule returns a result of "Nothing ........" when ping'd
>>
>> Just to be sure I wasn't mucking up the chain of rules I added this as the
>> only rule to test it out and have achieved the same result multiple times
>> on a test machine.
>>
>> Can anyone shed some light on the syntax and help me out with getting this
>> rule to make the system respond to a echo request with admin-prohib as the
>> destination system ?
>>
>> Thanks
>>
>
>
> *click* (the light is on)
>
> Options returning ICMP packets currently have no effect if pf(4)
> operates on a if_bridge(4), as the code to support this feature has
> not yet been implemented.
>
> from the Manual page. I think that answers the question?
>
Thanks Remko,
No I'm not using if_bridge(4) here, nor any bridge for that matter. I have
tested this directly from interface -> interface with a patch cable
thinking that the click that I heard from the light above would actually
turn something on but was just throwing a breaker.
I also have turned my WiFi NIC into a ad-hoc connection and threw the rule
on it instead of the test box and then ran a ping(8) from a direct connect
and the same thing happens. Same thing from directly connecting to the AP.
So unless what you are telling me above is that all interfaces no matter
what they are, operate in a bridge mode and the code is missing then I am
really confused. -- This does not need to be answered as I know that's not
the case.
Or the code is just missing to do this all together, in turn I would like
to throw a voiced question of "where did it go ?" this was in IPF before
pf started making its way through the circuit.
The conclusion from what I see thus far is that all the return-icmp*
context in the pf.conf(5) man page is false for FreeBSD at least 7.2 right
now, as I can't account for earlier or later releases at this point.
FreeBSD 7.2-STABLE #0 r198446: Sun Oct 25 16:40:39 EDT 2009
Still obtaining small flicker of light from circuit breaker,
Best regards.
--
;; dataix.net!jhell 2048R/89D8547E 2009-09-30
;; BSD since FreeBSD 4.2 Linux since Slackware 2.1
;; 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E
------------------------------
End of freebsd-pf Digest, Vol 266, Issue 2
******************************************