Am 06/22/17 um 16:49 schrieb Stuart Henderson:
> On 2017/06/22 16:05, Marc Peters wrote:
>> Am 06/22/17 um 15:30 schrieb Stuart Henderson:
>>>
>>> How are your PF rules? Do they allow NDP packets to pass? If you're
>>> unsure, I would try "pass log inet6 proto icmp6" or similar.
>>>
>>> (this might be a bit of a surprise if used to IPv4 where address
>>> resolution is done by a separate protocol that PF doesn't block).
>>>
>>
>> I don't block any icmp6:
>> pass inet6 proto icmp6 all
>>
>> is already present in my /etc/pf.conf
> 
> Are there any other rules which might interfere with this one? This
> issue feels very much like NDP not getting through in some circumstances.

Here is the running set:
~ # pfctl -sr
block drop log all
block drop in log quick from <bad-ssh> to any
match in all scrub (no-df random-id)
match log (matches) proto ipv6-icmp all
pass out on egress proto tcp all flags S/SA
pass out on egress proto udp all
pass out on egress proto icmp all
pass in on em0 inet proto tcp from any to 136.243.67.92 port = 22 flags
S/SA keep state (source-track rule, max-src-conn 15
, max-src-conn-rate 2/60, overload <bad-ssh> flush global, src.track 60)
pass in on em0 inet6 proto tcp from any to fe80::3285:a9ff:fea4:ce5e
port = 22 flags S/SA keep state (source-track rule, ma
x-src-conn 15, max-src-conn-rate 2/60, overload <bad-ssh> flush global,
src.track 60)
pass in on em0 inet6 proto tcp from any to 2a01:4f8:212:216c::2 port =
22 flags S/SA keep state (source-track rule, max-src
-conn 15, max-src-conn-rate 2/60, overload <bad-ssh> flush global,
src.track 60)
pass in on em0 inet6 proto tcp from any to 2a01:4f8:212:216c::25 port =
22 flags S/SA keep state (source-track rule, max-sr
c-conn 15, max-src-conn-rate 2/60, overload <bad-ssh> flush global,
src.track 60)
pass in on em0 inet6 proto tcp from any to 2a01:4f8:212:216c::1:443 port
= 22 flags S/SA keep state (source-track rule, max
-src-conn 15, max-src-conn-rate 2/60, overload <bad-ssh> flush global,
src.track 60)
pass in on em0 inet6 proto tcp from any to fe80::3285:a9ff:fea4:ce5e
port = 587 flags S/SA
pass in on em0 inet6 proto tcp from any to 2a01:4f8:212:216c::2 port =
587 flags S/SA
pass in on em0 inet6 proto tcp from any to 2a01:4f8:212:216c::25 port =
587 flags S/SA
pass in on em0 inet6 proto tcp from any to 2a01:4f8:212:216c::1:443 port
= 587 flags S/SA
pass in on em0 inet6 proto tcp from any to fe80::3285:a9ff:fea4:ce5e
port = 993 flags S/SA
pass in on em0 inet6 proto tcp from any to 2a01:4f8:212:216c::2 port =
993 flags S/SA
pass in on em0 inet6 proto tcp from any to 2a01:4f8:212:216c::25 port =
993 flags S/SA
pass in on em0 inet6 proto tcp from any to 2a01:4f8:212:216c::1:443 port
= 993 flags S/SA
pass in on em0 inet proto tcp from any to 136.243.67.92 port = 587 flags
S/SA
pass in on em0 inet proto tcp from any to 136.243.67.92 port = 993 flags
S/SA
pass in on em0 proto udp from any to any port 33433 >< 33626
pass inet proto icmp all icmp-type echoreq
pass inet6 proto ipv6-icmp all
pass in log on egress inet proto tcp from any to any port = 25 flags
S/SA rdr-to 127.0.0.1 port 8025
pass in log (to pflog1) on egress proto tcp from <nospamd> to any port =
25 flags S/SA
pass in log (to pflog1) on egress proto tcp from <spamd-white> to any
port = 25 flags S/SA
pass in log (to pflog1) on egress inet6 proto tcp from any to any port =
25 flags S/SA
pass in log (to pflog1) quick on egress proto tcp from
<bgp-spamd-bypass> to any port = 25 flags S/SA
pass out log (to pflog1) on egress proto tcp from any to any port = 25
flags S/SA
pass in on em0 inet6 proto tcp from any to fe80::3285:a9ff:fea4:ce5e
port = 80 flags S/SA
pass in on em0 inet6 proto tcp from any to 2a01:4f8:212:216c::2 port =
80 flags S/SA
pass in on em0 inet6 proto tcp from any to 2a01:4f8:212:216c::25 port =
80 flags S/SA
pass in on em0 inet6 proto tcp from any to 2a01:4f8:212:216c::1:443 port
= 80 flags S/SA
pass in on em0 inet6 proto tcp from any to fe80::3285:a9ff:fea4:ce5e
port = 443 flags S/SA
pass in on em0 inet6 proto tcp from any to 2a01:4f8:212:216c::2 port =
443 flags S/SA
pass in on em0 inet6 proto tcp from any to 2a01:4f8:212:216c::25 port =
443 flags S/SA
pass in on em0 inet6 proto tcp from any to 2a01:4f8:212:216c::1:443 port
= 443 flags S/SA
pass in on em0 inet proto tcp from any to 136.243.67.92 port = 80 flags S/SA
pass in on em0 inet proto tcp from any to 136.243.67.92 port = 443 flags
S/SA
block drop in on ! lo0 proto tcp from any to any port 6000:6010
block drop in on ! lo inet6 from ::1 to any
block drop in on ! lo inet from 127.0.0.0/8 to any
block drop in inet6 from ::1 to any
block drop in on lo0 inet6 from fe80::1 to any
block drop in on ! em0 inet6 from 2a01:4f8:212:216c::/64 to any
block drop in on em0 inet6 from fe80::3285:a9ff:fea4:ce5e to any
block drop in inet6 from 2a01:4f8:212:216c::2 to any
block drop in inet6 from 2a01:4f8:212:216c::25 to any
block drop in inet6 from 2a01:4f8:212:216c::1:443 to any
block drop in inet from 127.0.0.1 to any
block drop in on ! em0 inet from 136.243.67.64/26 to any
block drop in inet from 136.243.67.92 to any

> 
> For instance I had problems at an IXP where one peer was sourcing the
> NDP from an fe80:: address which was getting blocked by a too-restrictive
> "drop junk packets" type of rule. Everyone else was sending them with a
> "real" source address which wasn't triggering that rule - it took a
> while to track down!
> 
> I would want to be 100% sure of this before digging deeper (e.g. with
> "match log(matches) proto icmp6" at the top of the ruleset and watching
> pflog when flushing ndp).

flushed and try to ping google:
~ # tcpdump -eni pflog0

tcpdump: WARNING: snaplen raised from 116 to 160

tcpdump: listening on pflog0, link-type PFLOG

17:51:40.802154 rule 3/(match) match out on em0:
fe80::3285:a9ff:fea4:ce5e > fe80::1: [|icmp6]
17:51:40.802161 rule 24/(match) pass out on em0:
fe80::3285:a9ff:fea4:ce5e > fe80::1: [|icmp6]
17:51:40.802164 rule 24/(match) pass out on em0:
fe80::3285:a9ff:fea4:ce5e > fe80::1: [|icmp6]
17:51:44.315096 rule 0/(match) block in on em0: 14.102.54.71.44014 >
136.243.67.92.23: S 2297643868:2297643868(0) win 17694
17:51:54.352603 rule 0/(match) block in on em0: 183.83.2.130.17434 >
136.243.67.92.23: S 2297643868:2297643868(0) win 8562
17:52:10.602114 rule 3/(match) match out on em0:
fe80::3285:a9ff:fea4:ce5e > fe80::1: [|icmp6]
17:52:10.602120 rule 24/(match) pass out on em0:
fe80::3285:a9ff:fea4:ce5e > fe80::1: [|icmp6]
17:52:10.602125 rule 24/(match) pass out on em0:
fe80::3285:a9ff:fea4:ce5e > fe80::1: [|icmp6]
17:52:12.006267 rule 0/(match) block in on em0: 91.223.133.13.58044 >
136.243.67.92.4447: S 3013916555:3013916555(0) win 10
24

17:52:16.856321 rule 0/(match) block in on em0: 61.231.101.145.59990 >
136.243.67.92.445: S 4146551513:4146551513(0) win 81
92 <mss 1440,nop,wscale 2,nop,nop,sackOK> (DF)













17:52:40.782015 rule 3/(match) match out on em0:
fe80::3285:a9ff:fea4:ce5e > fe80::1: [|icmp6]
17:52:40.782021 rule 24/(match) pass out on em0:
fe80::3285:a9ff:fea4:ce5e > fe80::1: [|icmp6]
17:52:40.782026 rule 24/(match) pass out on em0:
fe80::3285:a9ff:fea4:ce5e > fe80::1: [|icmp6]
17:52:55.907212 rule 3/(match) match out on em0:
2a01:4f8:212:216c::1:443 > 2a00:1450:4001:821::2003: icmp6: echo request
17:52:55.907217 rule 24/(match) pass out on em0:
2a01:4f8:212:216c::1:443 > 2a00:1450:4001:821::2003: icmp6: echo request
17:52:55.907221 rule 24/(match) pass out on em0:
2a01:4f8:212:216c::1:443 > 2a00:1450:4001:821::2003: icmp6: echo request
17:52:55.907233 rule 3/(match) match out on em0:
2a01:4f8:212:216c::1:443 > ff02::1:ff00:1: [|icmp6]
17:52:55.907237 rule 24/(match) pass out on em0:
2a01:4f8:212:216c::1:443 > ff02::1:ff00:1: [|icmp6]
17:52:55.907240 rule 24/(match) pass out on em0:
2a01:4f8:212:216c::1:443 > ff02::1:ff00:1: [|icmp6]
17:53:35.791950 rule 3/(match) match out on em0:
2a01:4f8:212:216c::1:443 > ff02::1:ff00:1: [|icmp6]
17:53:35.791956 rule 24/(match) pass out on em0:
2a01:4f8:212:216c::1:443 > ff02::1:ff00:1: [|icmp6]
17:53:35.791960 rule 24/(match) pass out on em0:
2a01:4f8:212:216c::1:443 > ff02::1:ff00:1: [|icmp6]
^C
22 packets received by filter

> 
> I think the step after that would be seeing what you get from nd6 debug
> messages, either you can build a kernel with the ND6_DEBUG option, or if
> you can break into DDB, you don't actually need a new kernel, just
> 'w nd6_debug 1' and 'c' should do the trick - then see what shows up
> in /var/log/messages.
> 

I would prefer the new kernel for this, as this is an offsite machine.

Reply via email to