Weirdness with IPv6 and DHCPv6...

[Saarbremer]

Ok, I think we're looking at the wrong place here.

If you can ping your ISP's gateway from LAN and the ISP's gateway is a link local address, that sounds to me as if your LAN is physically connected to your WAN. Is there some misconfigured switch between hosts and OPNsense? Or maybe some non-functional Proxmox setup?

Pinging a host with a link-local address that is not part of your network segment usually is just impossible.

[Ed V.]

It's a pretty simplistic network:



I say the "Provided" gateway as in the LAN 2009:... which is from the Cox allocation.

The two fe80: IP's on the WAN side are "Unreachable".

Code: [Select]

C:\Windows\System32>ping 2001:579:4c:3700:2e0:67ff:fe1f:2529

Pinging 2001:579:4c:3700:2e0:67ff:fe1f:2529 with 32 bytes of data:
Reply from 2001:579:4c:3700:2e0:67ff:fe1f:2529: time<1ms
Reply from 2001:579:4c:3700:2e0:67ff:fe1f:2529: time<1ms
Reply from 2001:579:4c:3700:2e0:67ff:fe1f:2529: time<1ms
Reply from 2001:579:4c:3700:2e0:67ff:fe1f:2529: time<1ms

Ping statistics for 2001:579:4c:3700:2e0:67ff:fe1f:2529:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Windows\System32>ping fe80::2e0:67ff:fe1f:2528

Pinging fe80::2e0:67ff:fe1f:2528 with 32 bytes of data:
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.

Ping statistics for fe80::2e0:67ff:fe1f:2528:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Windows\System32>ping fe80::2ef8:9bff:fe9d:b419

Pinging fe80::2ef8:9bff:fe9d:b419 with 32 bytes of data:
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.

Ping statistics for fe80::2ef8:9bff:fe9d:b419:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Windows\System32>

[zan]

You're not supposed to be able to ping your WAN's LLA from your LAN clients because of different segments.
RA daemon should advertise your LAN's LLA as default gateway to your LAN clients.
What is the LLA of your LAN interface? Can you post the output of ifconfig igb1?
So your LAN's LLA is fe80::2e0:67ff:fe1f:2529 and reachable by your LAN clients. This should be advertised by radvd but for some reasons your clients don't use it as default gateway. Is it only affecting your Windows machine?

[Saarbremer]

Did you restart radvd and dhcpv6 service after the configuration change to advertise the default gateway?

[Ed V.]

In order:

1 - At least for my deployment, I think I've solved the problem.
2 - Yes, it was happening across all platforms (Windows, Linux, MacOS, Android, Network /Switch gear, etc.)
3 - Yes, I restarted radvd and dhcpdv6 after each "Save /Apply".

I got frustrated last night and rolled back to v24.1.1.

As expected, IPv6 worked "normally".

I did find that (from the web console):
1 - The ISC DHCPv6 configuration did not need to have the range configured to function
2 - Router Advertisements was not enabled
3 - There was a set of "Automatically generated rules" that allowed ICMPv6 for LAN and WAN

So I went back to v24.1.2 (still no IPv6 connectivity) and made one change.

I created a rule for both LAN and WAN that allowed all ICMPv6.

Even though there are "Automatically generated rule"(s) that look identical to the ICMPv6 rules in place in v24.1.1 on both interfaces, once I created the Custom rule, IPv6 started working.

Disable the Custom ICMPv6 rule - IPv6 "breaks" again...

Maybe it's my hardware - maybe I'm just unlucky, but with all the great help and ideas /guidance /troubleshooting here at least it's now working...

[Saarbremer]

Thanks for sharing. It sounds quite strange but may explain what happened.

Could you share your custom rule with is. I am really curious about it.

[Ed V.]

It's the most basic and simple of rules:

Code: [Select]

pass in quick on igb1 inet6 proto ipv6-icmp all keep state (LAN)

Code: [Select]

pass in quick on igb0 inet6 proto ipv6-icmp all keep state (WAN)

or



I thought about trying to build out a duplicate of the RFC4890 "Automatic" rules, but once I read a bit more and realized that since, by design, ICMPv6 doesn't pose the same sort of Command and Control /data leakage risk that ICMPv4 does, I used a "blanket" rule.

If you know of any reason why that might be "bad", let me know and I'll build the duplicates...

[JamesFrisch]

Thanks Ed! So I am not hallucinating 

I have the same problem since switching from pfSense to opnsense.
https://forum.opnsense.org/index.php?topic=39033.msg191804#msg191804

[Wirehead]

Been having the same issue since 24.1.2.

IPv6 acting up. Here on a Dual-WAN set-up as well.

Can be seen when doing a ping6 etc,...
Clients get a  "ICMPv6 Destination Unreachable (Address unreachable)" from the local gateway; but both IPv6 gateways are working and up.

[Saarbremer]

Would be interesting to find out why this was missing in the first place. On my 24.1.2_1 everything works fine and I have automatic generated IPV6-ICMP rules for * * * * and ICMP6 types 1,2,135,136

[Ed V.]

The Automatically Generated Rules for ICMPv6 are present in my 24.1.2 system:


But for whatever reason, IPv6 does not work without the custom /manual ICMPv6 rule.

I've reverted to 24.1.1 and re-upgraded to 24.1.2 twice, with a "Factory Default" reset each time and on 24.1.2 IPv6 does not work until I put the ICMPv6 rule in place.

If there's further debug /troubleshooting data that would help isolate the issue, I'm game to track /search and post...

[Saarbremer]

Hover your mouse over "IPV6-ICMP" and it tells you which message types it actually refers to. The UI is quite restrictive here. Furthermore, those rules do not exist in any config. They are generated automatically. At least this is what the most recent source tells me.

Ping (echo request, reply) is not enabled by default. Type is not allowed.

[Ed V.]

Wow - yup.

Hadn't tried the "hover" reveal, but the list of ICMPv6 types is not at all complete per RFC 4890.

I've been searching and can't find where OPNSense defines ICMP /ICMPv6 Types or how to build PF rules where a type is not named (the "Undefined" numerics).

The only ICMPv6 types that I can see in-use are:

• Type 1 Destination Unreachable (unreach)
• Type 2 Packet Too Big (toobig)
• Type 128 Echo Request (echoreq)
• Type 129 Echo Reply (echorep)
• Type 133 Router Solicitation (routersol)
• Type 134 Router Advertisement (routeradv)
• Type 135 Neighbor Solicitation (neighborsol)
• Type 136 Neighbor Advertisement (neighboradv)

With a few more pre-defined in the "drop-down" but those look more like they are comingled with ICMPv4 from a strict "Human readable name" perspective.

I see an array in /usr/local/www/firewall_rules.php, but I'm not willing to edit that and I don't see any of the icmp6types showing up in the WebUI.

Anyone have a good link /doc where I can use the WebUI or command line (pfctl) to define types /codes, add them by number to a table, or otherwise build correct rules?

It feels like the WebUI is not robust /flexible enough (unless I've missed something) so I am likely stuck adding rules via command line...

If my read is correct, then the "Automatic" rules for ICMPv6 should encompass:

Transit through the Firewall:
Must Not Drop (§4.3.1):
  Type 1, Type 2, Type 3 Code 0, Type 4 Code 1, Type 4 Code 2, Type 128-129
Should Not Drop (§4.3.2):
  Type 3 Code 1, Type 4 Code 0, Type 144-147
Needs a rule (§4.3.4):
  Must Allow:
   Seamoby
    Type 150
   Undefined Error Messages:
    Type 5-99, 102-126
   Unallocated Informational Messages:
    Type 154-199
    Type 202-254

Not sure about these - maybe a "checkbox" somewhere to turn them on?
Should Drop barring defined need (§4.3.5):
Type 100-101, Type 127, Type 138-140, Type 200-201, Type 255

Local Traffic (LAN, WAN, Link Local, etc.):
Must Not Drop (§4.4.1):
Type 1, Type 2, Type 3 Code 0, Type 4 Code 1, Type 4 Code 2, Type 128-136, Type 141-143, Type 148, Type 149, Type 151-153
Should Not Drop (§4.4.2):
Type 3 Code 1, Type 4 Code 0
Needs a Rule (4.4.4):
  Must Allow:
   Type 137
  If Experimental:
   Type 139-140
  Undefined Error Messages:
   Type 5-99
   Type 102-126

Not sure about these - maybe a "checkbox" somewhere to turn them on?
Should Drop barring defined need (§4.4.5):
Type 100-101, 127
Type 154-199
Type 200-255

[Ed V.]

Oddly, I just ran across a forum topic from 2019 that looked like it was going to help /maybe resolve the issue - but then the author got distracted and never tested /implemented the update code..

https://forum.opnsense.org/index.php?topic=14891.0