Re: NPF does not recognize npflog0

["S.P.Zeidler" <spz%serpens.de@localhost>]

Hi,

Thus wrote Pongthep Kulkrisada (ptkrisada%gmail.com@localhost):

> * S.P.Zeidler (spz%serpens.de@localhost) wrote:
> > Have you tried also allowing
> > pass final on $ext_if family inet proto icmp icmp-type echo-reply all?
> Thank you very much for your reply.
> But please note a typo, it is ``echoreply'' (without a dash).

correct. For inet4, it's the strings from src/sys/netinet/ip_icmp.h
icmp_type, for inet6 it's src/sys/netinet/icmp6.h icmp6_type_info and
icmp6_type_err.

> either
>     pass final on $ext_if family inet proto icmp icmp-type echoreply all
> or
>     pass final on $ext_if family inet proto icmp icmp-type echoreply code 0 
> all
> The behavior is the same.

since only code 0 is defined for echoreply, normally all packets should
have code 0 and thus the rules should behave the same (for well-behaved
communication partners, that is).

> NetBSD box can ping the other machines.

As long as you allow your "proto icmp icmp-type echo" packets to go out.

> But the other machines cannot ping my NetBSD box.

Well, for that you would have to allow "proto icmp icmp-type echo" packets
to come in :)

> If want to ping both sides, the only rule works i.e.
>     pass final on $ext_if family inet proto icmp all
> unless an additional rule of ``echoreq'' is added.

It should be just "echo", I think.

But yes, one type of packet goes out, another type of packet comes back
(or one type of packet comes in, another goes out).

Note that if your ping met interesting times on its trip and instead of
a echo reply an error packet came back, you would not see it if you just
allowed echo/echoreply. The possibilities of shooting yourself in the foot
by default-blocking icmp are plenty. :) And IPv6 depends on ICMP working
even more.

regards,
        spz
-- 
spz%serpens.de@localhost (S.P.Zeidler)