return-icmp() relative question to ipf rule.

[jhell]

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

--

  ;; 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

_______________________________________________
freebsd-pf@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscribe@..."

[Remko Lodder-2]

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,                        | remko@...
\ /   Remko Lodder                      | remko@EFnet
X    http://www.evilcoder.org/    |
/ \   ASCII Ribbon Campaign    | Against HTML Mail and News

_______________________________________________
freebsd-pf@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscribe@..."

[jhell]

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

_______________________________________________
freebsd-pf@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscribe@..."

[Remko Lodder-2]

On Oct 26, 2009, at 4:02 PM, jhell wrote:

>
> 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.

OK, yes I understand what you mean. I over-read the bridge part. My  
apologies for the confusion this caused. I am not sure whether it then  
should or should not work though. One thing that I noticed is that you  
speak about
'it was in IPF and it isn't in PF', please keep in mind that PF is a  
complete rewrite and looks similiar to IPF with syntax etc. Features  
found there are no guarantee that it will be in PF as well. Doesn't  
make up the fact that the
documentation indeed talks about it being possible and seemingly  
impossible to do it.

I added Max to the discussion, he might be able to tell whether or not  
this is integrated and whether it should work at all :-)

Thanks for catching my misread part!

--
/"\   Best regards,                        | remko@...
\ /   Remko Lodder                      | remko@EFnet
X    http://www.evilcoder.org/    |
/ \   ASCII Ribbon Campaign    | Against HTML Mail and News

_______________________________________________
freebsd-pf@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscribe@..."

[jhell]

On Wed, 28 Oct 2009 04:23, remko@ wrote:

> On Oct 26, 2009, at 4:02 PM, jhell wrote:
>
>>
>> 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.
>
>
> OK, yes I understand what you mean. I over-read the bridge part. My apologies
> for the confusion this caused. I am not sure whether it then should or should
> not work though. One thing that I noticed is that you speak about
> 'it was in IPF and it isn't in PF', please keep in mind that PF is a complete
> rewrite and looks similiar to IPF with syntax etc. Features found there are
> no guarantee that it will be in PF as well. Doesn't make up the fact that the
> documentation indeed talks about it being possible and seemingly impossible
> to do it.
>
> I added Max to the discussion, he might be able to tell whether or not this
> is integrated and whether it should work at all :-)
>
> Thanks for catching my misread part!
>

Hey its no problem at all, I appreciate the feedback because I thought
that possibly I might have missed something that wasn't allowing it to work
but I have tried all kinds of trickery around the likes of adding pass out
all rules of type ICMP with specific codes and such before and after the
rule in question and nothing seems to do it. So some input on this was
better than none at all. Thanks for your response and can't wait for some
more interaction on this thread as this has now just become a annoying
unreachable objective for me.


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

_______________________________________________
freebsd-pf@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscribe@..."