IPv6 FW Rule from WAN IP to ff02 missing (NDP)

[bbaumer]

Freshinstall on Version: 18.7.8

Setup:
Static IPv6 Address on WAN. The ISP-Gateway is on the same Net (Transfer-Net).
After Reboot no IPv6 Communication is possible, because the Neighbor-Discovery can not be completed.

There is an outgoing pass Rule from the WAN-IP to ff02::/16 for icmp6-type 135 (Neighbor Solicitation) missing.
This Rule should be automatically generated.

Workaround:
Generate a Floating Firewall-Rule on the Webinterface with following parameters:
Action: Pass
Quick: Enabled
Interface: Your WAN
Direction: out
TCP/IP Version: IPv6
Protocol: IPV6-ICMP
Source: WAN address
Destination: ff02::/16
Advanced -> disbale reply-to: Enabled

[fichtner]

We do have all of these hardwired:

pass in log quick inet6 proto ipv6-icmp from {any} to {any} icmp6-type {1,2,135,136} keep state label "IPv6 requirements (ICMP)"
pass out log quick inet6 proto ipv6-icmp from {fe80::/10} to {fe80::/10,ff02::/16} icmp6-type {129,133,134,135,136} keep state label "IPv6 requirements (ICMP)"
pass in log quick inet6 proto ipv6-icmp from {fe80::/10} to {fe80::/10,ff02::/16} icmp6-type {128,133,134,135,136} keep state label "IPv6 requirements (ICMP)"
pass in log quick inet6 proto ipv6-icmp from {ff02::/16} to {fe80::/10} icmp6-type {128,133,134,135,136} keep state label "IPv6 requirements (ICMP)"

From your description it looks like this one is "mismatching":

pass out log quick inet6 proto ipv6-icmp from {fe80::/10} to {fe80::/10,ff02::/16} icmp6-type {129,133,134,135,136} keep state label "IPv6 requirements (ICMP)"

The only reason why that would happen is fe80::/10 is not being used as traffic source?

[AdSchellevis]

If I'm understanding the rfc correctly, the router should broadcast itself using it's own address, which in our case is send to the gateway instead of being multicasted:

https://tools.ietf.org/html/rfc4861
On multicast-capable links, each router periodically multicasts a
Router Advertisement packet announcing its availability. A host
receives Router Advertisements from all routers, building a list of
default routers. Routers generate Router Advertisements frequently
enough that hosts will learn of their presence within a few minutes,
but not frequently enough to rely on an absence of advertisements to
detect router failure; a separate Neighbor Unreachability Detection
algorithm provides failure detection.

that would mean we should discard route-to for our outbound ipv6-icmp to ff02::/16 traffic, right?

[fichtner]

where would reply-to be set?

[fichtner]

sorry, route-to.. do you mean "let out anything from firewall host itself" ?

[AdSchellevis]

yes, my mistake, I was just looking for the exact reference, but that's it. I can fix this later if you like. we should probably add a rule here, since we also have the others in there too.

[fichtner]

but shouldn't the hardcoded ipv6 quick pass without the route-to already catch this?

[AdSchellevis]

no, since it's not using fe80::/10, but it's own address to multicast (again, assuming I read the rfc correctly)

[fichtner]

why not set from {fe80::/10,ff02::/16} for the out rule then?

[AdSchellevis]

and just drop the from part, that would probably be fine too, easiest fix if you ask me.

[fichtner]

I see, it would send from its global address oO

[fichtner]

@bbaumer one question, do you have IPv6 Upstream Gateway set under WAN or left it at "auto-detect" ?

[mahescho]

I've the same problem with 18.7.8-amd64 and a static internet connection. For me @bbaumer s workaround does not work. I've to do "pfctl -d" and then "pfctl -e" to make it work.

[bbaumer]

@fichtner: I tried both Settings "IPv6 Upstream Gateway" and "auto-detect". It makes no difference. Actually it is set to "auto-detect".

[AdSchellevis]

@bbaumer can you try c3213d4 ?

[fichtner]

I want to work on a related oddity still :)

[bbaumer]

I've the same problem with 18.7.8-amd64 and a static internet connection. For me @bbaumer s workaround does not work. I've to do "pfctl -d" and then "pfctl -e" to make it work.

"pfctl -d" and then "pfctl -e" will only temporarly fix the Problem, because Entries in the Neighbor-Table have a Lifetime (24h). You can look at the Entries with ndp -atn

[mahescho]

@bbaumer can you try c3213d4 ?

This fixed the issue for me with 18.7.8-amd64 !

[fichtner]

It's in 18.7.9, closing.