Enhancement: Change the address ranges used inside Qubes

noseshimself commented 5 years ago

Qubes OS version:

R4.0

Affected component(s):

Steps to reproduce the behavior:

Qubes is using segments from NET-10 for its own use in between VMs. No matter which we're taking there, there is always a chance for address conflicts with network ranges the systems may connect to. Especially in the case of larger organizations (even for small values of "large") this will lead to conflicts because rearranging Qubes internal setup is quite difficult.

Is it possible to change this to (ab-)using other IP address ranges? Going to the APIPA area would be just as useless (even more because it would restrict most mobile users in broken environments like Asian hotels) but there are at least Class E (240.0.0.0/4 per RFC 1112) and the Internet benchmark net (198.18.0.0/15 per RFC 2544) that come to my mind. Especially 240.0.0.0/4 is already used by corporations running out of 1918 space...

Please consider a setup option or better a reconfiguration tool that would permit using other parts of the address space for Qubes' internal networking.

Expected behavior:

Actual behavior:

General notes:

Related issues:

marmarek commented 5 years ago

I don't think migrating to other range would be any better, regardless of what range it would be. You'll always find some conflicts. And if we abuse some, there may be even more unexpected consequences. On the other hand, we use /32 netmask, so conflicts matter only if you hit them at particular IP address, having "just" 10.x addressing in the same network should be fine, as long as those few IP used by your qubes do not conflict.

If they do conflict, you can adjust individual IP addresses using qvm-prefs <vmname> ip .... So, to some extend it is already configurable. Changing the whole range also could be done, a good task for community contributor.

unman commented 5 years ago

I was in the middle of a long reply when Marek posted. We really shouldn't abuse ranges. Where users wanted help this would just complicate the situation hugely. Imagine trying to explain to the average IT guy why your address is in one of those ranges. In most (normal?) usage, the issue wont arise. The use cases where conflict would arise are relatively small and already catered for, without the need for wholesale changes.

noseshimself commented 5 years ago

On 13.11.2018 14:19:37, "unman" notifications@github.com wrote:

I was in the middle of a long reply when Marek posted. We really shouldn't abuse ranges. Where users wanted help this would just complicate the situation hugely. Imagine trying to explain to the average IT guy why your address is in one of those ranges.

If "the local IT guy" sees the address(es) coming out of my machine something will be seriously broken in core Qubes functionality. I proposed them to be used for the internal network and they should never get around any NAT on the way.

In most (normal?) usage, the issue wont arise.

The internal use of 10.0.0.0/8 address space just cost me the permission to connect my machine (that would otherwise be aligned with corporate security regulations) to the network. Go figure.

The use cases where conflict would arise are relatively small and already catered for, without the need for wholesale changes.

What you call "use case" would be "aligning with corporate governance requirements".

I can of course modify the necessary parts of a Qubes installation but I'm a bit afraid of breaking future upgradability doing so.

Achim

unman commented 5 years ago

@noseshimself You missed the part where I said "where users wanted help". First thing IT would ask is "what's your IP address"

You dont say how the internal use cost you permission to connect. I would take that problem to the mailing list.

andrewdavidwong commented 5 years ago

Closing as "won't do." If anyone has a new reason for why this should be done, please leave a comment, and we'll be happy to take another look. Thank you.

QubesOS / qubes-issues