Routing IPv6 ULA across interfaces
-
I noticed something today on my network and I'm not sure how to best deal with this.
My Apple TV is on my Media (vlan 50 network). I also have some HomePod mini's also on the same vlan 50 network. I have some cameras on my Security (vlan 70 network) and those are added to HomeKit and available to watch within the Apple TV.
When I go to launch the camera feeds through the Apple TV though, I get a number of requests sent from an
fd00::/8address to anfd00::/8address using UDP, and using Wireshark I see it's using the STUN protocol. I currently have an allow rule that allows that traffic to be passed, but also to log that traffic. Here's what that looks like in my Splunk logs:
The thing is, I don't want an allow rule to allow
fd00::/8tofd00::/8, because that means this interface can talk to anything else that has a ULA address on my network, and I want to limit this network to only talk to specific VLAN networks.My assumption was that my
VL50_Media netsource in my firewall rules would include ULA addresses, but that doesn't appear to be the case (at least with how I have pfSense configured).
So, what am I doing incorrectly? From my reading, it sounds like I may need to generate my own ULA /64 PD and add that to my RA for each of my vlans? That way I have control over what the /64 of the ULA is per vlan, and then I can add those to my firewall rules?
Attached is a pcap as well in case that's helpful:
ula.pcapng -
Normally, you do have to create your own ULA prefixes. How are they being created now? Also, what's causing the STUN requests? STUN is normally used to get through NAT for things such as VoIP. Also, the STUN source and destination are within the same /64 prefix, which means they wouldn't be passing through pfSense.
-
@jknott said in Routing IPv6 ULA across interfaces:
Normally, you do have to create your own ULA prefixes. How are they being created now? Also, what's causing the STUN requests? STUN is normally used to get through NAT for things such as VoIP. Also, the STUN source and destination are within the same /64 prefix, which means they wouldn't be passing through pfSense.
@JKnott They're being created on their own. I'm not an expert here, but it appears to be only coming from the latest Apple TV 4K gen2, and a HomePod Mini or two.
Those devices (Apple TV and HomePod Mini) are creating those STUN requests. Maybe that's to see if their ULA address can reach the internet using NPt?
Those devices support the Thread Protocol, which communicates via IPv6 and uses ULA addresses:
https://openthread.io/guides/thread-primer/ipv6-addressingThey appear to create their own ULA addresses that have nothing to do with my router (pfSense), and since I don't run a consumer router that allows all by default and only has a single subnet, things start getting blocked.
As a test, I updated some of my interface RA's to now include
fd00:bad:beef:50::\64as a subnet (changing the last two numbers to match my vlan numbers. I want to see if this replaces the ULA these Apple devices create on their own, with the one that pfSense then provides. If that works, then I can add those as firewall rules to direct the traffic where I'm okay with it going.Interesting thing I noticed though, the RA page states this for the subnets:
Subnets are specified in CIDR format. Select the CIDR mask that pertains to each entry. /128 specifies a single IPv6 host; /64 specifies a normal IPv6 network; etc. If no subnets are specified here, the Router Advertisement (RA) Daemon will advertise to the subnet to which the router's interface is assigned.
I only specified the
fd00:bad:beef:50::/64subnet in there, but my devices still get global addresses assigned. That's a good thing... since I didn't want to specify my global addresses here since my IPv6 address is dynamic. But based on the wording, I would have thought my devices would only get that ULA address assigned to them. -
@offstageroller What your seeing sounds like this
https://discussions.apple.com/thread/252823422
If it was me - I would just drop that traffic and not log it.. Its NOISE that you do not seem to want on your network anyway. Doesn't seem from what I can find is a way to disable the feature on the apple TV.. I personally would return such a device that tries to use a protocol like that without a way for me to disable it.
That thread network stuff with endpoints, routers, and border routers. Seems to be a way mesh to work via IPv6 over the same network... Your segmenting your network would break such a setup.. When they come up with this stuff - they think with users running 1 flat network, not keeping in mind that more and more users are segmenting their networks. This shit doesn't work over it, and creates lots and lots of noise..
I am all for them coming up with ways to help the typical home user where shit just works - but they shouldn't forget not everyone is running 1 flat network where everything is on just 1 freaking L2.. And if your going to have devices creating their own networks over say bluetooth or their own wifi related networks - its going to cause problems... There should be a way to turn that stuff off the user doesn't want to use it.
-
@offstageroller said in Routing IPv6 ULA across interfaces:
They appear to create their own ULA addresses that have nothing to do with my router (pfSense), and since I don't run a consumer router that allows all by default and only has a single subnet, things start getting blocked.
Is your modem in bridge or router mode? The modem from my ISP provides both GUA and ULA addresses when in gateway mode.
-
@johnpoz said in Routing IPv6 ULA across interfaces:
@offstageroller What your seeing sounds like this
https://discussions.apple.com/thread/252823422
If it was me - I would just drop that traffic and not log it.. Its NOISE that you do not seem to want on your network anyway. Doesn't seem from what I can find is a way to disable the feature on the apple TV.. I personally would return such a device that tries to use a protocol like that without a way for me to disable it.
That thread network stuff with endpoints, routers, and border routers. Seems to be a way mesh to work via IPv6 over the same network... Your segmenting your network would break such a setup.. When they come up with this stuff - they think with users running 1 flat network, not keeping in mind that more and more users are segmenting their networks. This shit doesn't work over it, and creates lots and lots of noise..
I am all for them coming up with ways to help the typical home user where shit just works - but they shouldn't forget not everyone is running 1 flat network where everything is on just 1 freaking L2.. And if your going to have devices creating their own networks over say bluetooth or their own wifi related networks - its going to cause problems... There should be a way to turn that stuff off the user doesn't want to use it.
@johnpoz Yep, that's what I'm seeing.
I think your right in that I should not use ULA (I don't have a need for it on my home network), and therefore I should drop all ULA traffic and not log it.
This doc:
https://openthread.io/guides/thread-primer/ipv6-addressingSays this:
An EID that identifies a Thread interface, independent of network topology. Used to reach a Thread interface within the same Thread partition. Also called a Unique Local Address (ULA).
So basically the Thread protocol is creating its own IPv6 mesh network within my network. To your point, maybe that works in a flat network (but still isn't acceptable IMO), but that's not we setup our networks, and this protocol doesn't seem like it was designed for networks like ours.
I only have 1 WiFi device on my network that supports the thread protocol, but I have no interest in using Thread right now. Almost all of my IoT devices use Zigbee or ZWave along with HomeAssistant, and I prefer to build out those mesh networks that don't have anything to do with my pfSense/Unifi network.
I also agree that it should be configurable... but this is Apple. There's not even an option to turn off Thread if that's something I don't want to use.
I'll keep testing into the weekend. So far, the Thread network hasn't picked up my
fd00:bad:beef:50::/64subnet through my RA's. Based on the reading I've done on Thread, it won't pick that up, because it just ends up creating it's own mesh network and doesn't care about what pfSense tells it to use.In the end, I'll likely just create a rule to block and not log any
fd00::/8traffic, since there's nothing else on my network that uses or needs ULA addresses.Regarding my original reason for creating this topic, there's nothing pfSense can do about this. pfSense has no idea about what these Apple devices are doing with creating their own Thread IPv6 mesh network. So I either need to allow all of that traffic across all VLANs, which breaks my network isolation I currently have in place, or block it.
-
@jknott said in Routing IPv6 ULA across interfaces:
@offstageroller said in Routing IPv6 ULA across interfaces:
They appear to create their own ULA addresses that have nothing to do with my router (pfSense), and since I don't run a consumer router that allows all by default and only has a single subnet, things start getting blocked.
Is your modem in bridge or router mode? The modem from my ISP provides both GUA and ULA addresses when in gateway mode.
My modem is in bridge mode.
My pfSense WAN interface has a link local and global address assigned to it. My modem does not appear to be offering a ULA address to that interface.
-
L lamboalpha referenced this topic on
