In a firewall rule, what is included in "LAN net" for IPv6?

[JKnott]

@isaacfl said in In a firewall rule, what is included in "LAN net" for IPv6?:

ICMPv6 Src :: -> Dst ff02::2 Router Solicitation

What does the source address show? You'll need Wireshark to see that. You can download the Packet Capture capture file to view it in Wireshark.

[JKnott]

I just tried adding that rule and capturing the traffic as the test computer boots up. Wireshark shows the same as before, but Packet Capture now shows 14 packets captured, but none of them are DAD. Something strange is going on here. Packet Capture is running on the pfSense firewall and Wireshark on a computer connected via a managed switch, configured to mirror the traffic.

[IsaacFL]

@jknott said in In a firewall rule, what is included in "LAN net" for IPv6?:

@isaacfl said in In a firewall rule, what is included in "LAN net" for IPv6?:

ICMPv6 Src :: -> Dst ff02::2 Router Solicitation

What does the source address show? You'll need Wireshark to see that. You can download the Packet Capture capture file to view it in Wireshark.

I am seeing on Wireshark, that the source address is ::
it is coming from the Samsung Mac address.

[JKnott]

@isaacfl said in In a firewall rule, what is included in "LAN net" for IPv6?:

I am seeing on Wireshark, that the source address is ::
it is coming from the Samsung Mac address.

So, that brings us back to whether it's appropriate to use an unspecified address with a RS. Does it generate a RA when that rule is added? If so, what's the destination address?

[IsaacFL]

@jknott said in In a firewall rule, what is included in "LAN net" for IPv6?:

I just tried adding that rule and capturing the traffic as the test computer boots up. Wireshark shows the same as before, but Packet Capture now shows 14 packets captured, but none of them are DAD. Something strange is going on here. Packet Capture is running on the pfSense firewall and Wireshark on a computer connected via a managed switch, configured to mirror the traffic.

What I use for testing, is a "pass" rule, IPv6 "any" to "ff02::0/16"

Then if you use Wireshark, you will see pfsense participating more on the link.

When you disable the rule, not so much pfsense. Also, a lot of the traffic gets repeated, trying to find the router.

[JKnott]

@isaacfl said in In a firewall rule, what is included in "LAN net" for IPv6?:

ff02::0/16

I am getting more, just not the DAD. BTW, there's no difference between ff02::/16 and ff02::0/16. The :: simply means a string of 0 bits in the area specified.

When pfSense is updated to include the rule, they should test to make sure it is working properly. There shouldn't be any difference between PC and Wireshark.

[IsaacFL]

@jknott said in In a firewall rule, what is included in "LAN net" for IPv6?:

@isaacfl said in In a firewall rule, what is included in "LAN net" for IPv6?:

ff02::0/16

I am getting more, just not the DAD. BTW, there's no difference between ff02::/16 and ff02::0/16. The :: simply means a string of 0 bits in the area specified.

yeah, I had been trying more restrictive multicast addresses in my alias as part of my testing,

[JKnott]

@isaacfl said in In a firewall rule, what is included in "LAN net" for IPv6?:

I am seeing on Wireshark, that the source address is ::
it is coming from the Samsung Mac address.

Does it also show a DAD? It's supposed to be all but mandatory. Here's what RFC 4862 says:

"5.4. Duplicate Address Detection

Duplicate Address Detection MUST be performed on all unicast
addresses prior to assigning them to an interface, regardless of
whether they are obtained through stateless autoconfiguration,
DHCPv6, or manual configuration, with the following exceptions:

• An interface whose DupAddrDetectTransmits variable is set to zero
  does not perform Duplicate Address Detection.

• Duplicate Address Detection MUST NOT be performed on anycast
  addresses (note that anycast addresses cannot syntactically be
  distinguished from unicast addresses).

• Each individual unicast address SHOULD be tested for uniqueness.
  Note that there are implementations deployed that only perform
  Duplicate Address Detection for the link-local address and skip
  the test for the global address that uses the same interface
  identifier as that of the link-local address." ...

I doubt a TV would have that variable set to 0

[IsaacFL]

@jknott If I unplug the tv then back on, I see all what you are describing.

Once it is operating normally. I will see about every minute and a half I see about 6 or 7 ICMPv6 packets between the Samsung and pfSense:

Samsung sends:
[::] to [ff02::2] Length 63 Router Solicitation

pfsense responds:
[fe80::1:1] to [ff02::1] Length 198 Router Advertisement (includes prefix, domain, DNS, etc.)

Samsung responds with 2 packets, using it's link local address:
[fe80::56bd:79ff:fe17:54b] to [ff02::16] Length 90 Multicast Listener Report Message v2

pfsense responds:
[fe80:1:1] to [ff02::16] Length 90 Multicast Listener Report Message v2

That is the only time I see the [::] used as a source address.
It is some sort of joining a multicast conversation.

[IsaacFL]

@isaacfl I mistyped the record length above 63 should be 62.

[JKnott]

@isaacfl said in In a firewall rule, what is included in "LAN net" for IPv6?:

Once it is operating normally. I will see about every minute and a half I see about 6 or 7 ICMPv6 packets between the Samsung and pfSense:

You'd normally see DAD when a device first connects to a network, such as when powering up. Once it's verified the address, it won't need to do it again. Also, watch for it with Wireshark, as Packet Capture seems to miss DAD, even with that rule change. Still I don't understand why it would use :: after it's up & running. That sounds to me like a problem with that TV. It shouldn't be using the unspecified address when it knows it has a valid address, as it uses with those multicast listener reports. I also see pfSense is sending the RA to the all nodes address, as the RS doesn't contain a valid source address.

Based on what you've described, there is definitely a problem with that TV. Maybe you could contact Samsung and provide them with the info, including the stuff in the RFC. You'll likely have to escalate as first level support is unlikely to have a clue.

I've had to contact manufacturers a few times about a problem. It can take a fair bit of effort to reach the right person. On one occasion, many years ago, I found a bug in the Western Digital 8250 UART, which was used in the original IBM PC serial ports. After reaching an engineer, they verified I had found a bug that they were unaware of. There have also been a couple of times when I had to escalate problems with my ISP/cable provider, as the problem was well beyond what the first level support could even understand. I feel sorry for ordinary customers, who don't have the technical background I have, that would enable them to push a problem through to the right person.

[IsaacFL]

@jknott I have looked at the RFC 4861, and it says it is ok to use :: as the source address in a router solicitation.

RFC 4861 page 49:

"Router Solicitations in which the Source Address is the unspecified
address MUST NOT update the router's Neighbor Cache; solicitations
with a proper source address update the Neighbor Cache …"

So it is a router solicitation without updating the neighbor cache on the router.

[JKnott]

@isaacfl said in In a firewall rule, what is included in "LAN net" for IPv6?:

So it is a router solicitation without updating the neighbor cache on the router.

The question is why is that TV doing that? It should not be using the unspecified address for router solicitations. The reason why the cache is not updated is because that RS does not contain a valid address.

Can you upload a Wireshark, not Packet Capture, capture from boot up to after it stabilizes? I'd like to examine the entire sequence. If it's as bad as it sounds, you should be complaining to Samsung about their defective gear. This sounds about as brilliant as my Samsung Blu-ray player that no longer connects to the Internet.

[coreybrett]

@jimp This seems to have fixed my Android device as well. Before upgrade to 2.4.4, I was unable to have v6 running on my network because it would cause my cellphone to constantly drop it's WiFi connection because it though that it didn't have an Internet connection. After the upgrade, it works perfectly.