Paul - can you provide more specific information regarding the above? I’ve been working with someone who hasn’t been able to get some LAN drivers working and it turns out it was related to how he had his home network configured. Once he moved his hub and device to a 192.168.xxx.xxx address it worked, but the segments he was using prior (166.77.xxx.xxx) he couldn’t get the comms out of the hub. Exactly what address ranges are you restricting LAN drivers to use? Providing more specifics on this - and documenting it somewhere - would save people from struggling with these issues. Thanks!
Hi, @TAustin
I checked with the team and they mentioned 166.77.x.x Class B is not a private IP address space. That address space can (and will) contain public IP addresses in the New York area.
If you search for the ranges that are the reserved IPv4 addresses, you’ll find they are only:
10.0.0.0/8 IP addresses: 10.0.0.0 – 10.255.255.255
172.16.0.0/12 IP addresses: 172.16.0.0 – 172.31.255.255
192.168.0.0/16 IP addresses: 192.168.0.0 – 192.168.255.255
1 Like
So are those IPv4 ranges the ones that the hub is restricting us to? I want to make sure we have a direct answer as to what the hub is enforcing.
Thank you!
1 Like
Why should it matter whether they are public or private addresses? It’s short-sighted to assume that everyone will put their hub in private address space. If you want to restrict the LAN drivers to communicating only on the local LAN segment then restrict them to IP addresses in the local LAN subnet, regardless of the address space.
That is a great approach. Why add a layer of network complexity when there are other routes to enforce local LAN fencing. You know the ip network, you know the mask, therefore you know the range of hosts per subnet.
1 Like
Yes, the engineering team that there’s a restriction in the provided hostname for a connect operation where is validated that the IP address is one of the three private ranges.
As stated by others the CIDR ranges we restrict to for devices that have the “LAN” permission are those that are appropriate for use for a Local Area Network, the Private Network Address ranges. While it appears there is at least one user attempting to use a LAN on a non-private network address range, we do not and have no plans to support this non-standard network configuration that is out of alignment with RFC 1918: Address Allocation for Private Internets.
3 Likes
Local Area Network (LAN) ~= Private Network Addresses
While it is true that the vast majority of residential users follow the paradigm of using private addressing for their local networks and access the wide-area network (Internet) via NAT to public addresses, there is nothing in networking protocols that dictates the use of private or public addressing on a LAN. As I said previously, if you want to restrict the LAN drivers to communicating only on the local LAN segment then restrict them to IP addresses in the local LAN subnet, regardless of the address space.
Right, for now I guess you can interpret the “LAN” permission as being the permission that allows a driver to use networking protocols to talk to devices within the private address ranges. The primary goal here is to provide some (within reason) protection for users that a driver that has legitimate use to talk to a LAN device cannot trivially (e.g. without a proxy) begin exfiltrating data and phoning home to a service on the internet.
As you state, use of the subnet details may be another approach to achieve this, but it would likely also break the network setup of some users that are routing to other private network address ranges as part of their network infrastructure. I do generally believe that there is little or no legitimate use for establishing a LAN using a non-private address range (I am willing to be corrected) so for now I don’t see the system behavior changing.
A separate “internet” or similar permission is obviously something desired but separate from the “LAN” discussion I believe. We certainly don’t want to artificially preclude legitimate use cases and, of note, our own first party drivers abide by the same restrictions enforced by the permissions model.
2 Likes
I agree. I’ve never seen a product that supports a concept of a private LAN outside of the accepted IP ranges. Its a known and accepted practice. Someone that assigns their private LAN addresses outside of those ranges are just asking for trouble.
When I worked, it was standard for me to have a non-routed public IP space for my home LAN. The purpose is to avoid collisions of my private IP space that might also be in use when I VPN into a client’s site.
I learned later that there’s a market for non-routed public IP spaces… I got mine back in the 80s when anybody who wanted one for experimentation could get one, unfortunately, I didn’t keep the contact records for it up to date… and ARIN won’t accept my authority to release the addresses.
OTOH, if I were actually to do something like this again…I’d have a mix of vlans, with IoT in a private vlan. Along with home media sharing, which was another case I ran into that wouldn’t work with a non-routed public IP. (at one time I had a home network with 20+ vlans… then I almost died, and when I got out of the hospital… I learned that all my stuff was gone…another reason 2020 sucked.)