optional static IP addresses

[adrelanos]

For Qubes-Whonix we really could use static IP addresses. The current postinst / dpkg-triggers / search / replace-ips of internal IP addresses in config files approach is really something I dislike like because of the extra complexity layer that adds on top.

(The current implementation is derived from the fact, that a lot configuration files do not support variables. Worse so, a lot do not provide .d config snippet mechanisms.)

In Whonix hidden services instructions there is a chapter that suggests to torrc.

HiddenServicePort 80 IP-of-Qubes-Whonix-Workstation-AppVM:80

That is bad, because AppVM IPs can change. Also this is currently not covered by the replace-ips mechanism. (I wouldn't know how this could be implemented.)

Although ideally we could keep the 10.152.152.10 IP range. Was painful when we changed from 192 to 10. ( https://forums.whonix.org/t/implemented-feature-request-suggestion-gw-network-settings/118 ) More scalable. Provides more IP addresses. Leaks even less likely, due to different subnets. Less confusion by "does it conflict with my router". (Some more discussion on 10.152.152.10 in #1143 (comment) .)

[john-david-r-smith]

in this context, i want to add what i would want of static ips.

1. they have to be user-defined (both: vm and gateway ip. the gateway ip may always be at a offset, e.g. +0.0.1.0 => vm = 1.2.3.4 -> gateway = 1.2.4.4).
2. they should be backed up and restored from backups (there should be a dialog if restored vms have conflicting ips and the user should have the option to change one of them)
3. if a vm has no netvm, it keeps its static ip

[marmarek]

3. if a vm has no netvm, it keeps its static ip

Why?

As for other points, even conflicting IPs wouldn't be a problem with few tricks (#1143). Such VMs would not be able to communicate with each other, but that shouldn't be a problem.

[john-david-r-smith]

case A)
let A be a vm with a static ip.
for some reason i disconnected A temporarely (e.g. restructuring of the network vm network).
now i reconnect it.
A should keep its old ip.

case B)
i use some network disconnected hvm A in combination with a second vm B.
both should communicate per network.
i have two options of doing this:
B.1) i create a third vm C and set it as netvm for A and B.
now i have to configure C so the traffic passes through.
=> 3 vms + additional configuration
B.2) i set B as netvm of A.
no additional configuration is required (except adding the network-manager service)
=> 2 vms + nearly no additional configuration => easier to set up + less ram required
but currently B has no ip, since it has no netvm.

in all cases i would like a static ip, since i can set it to something i can remember.

would providing an ip to vms without netvm pose a problem?

[marmarek]

would providing an ip to vms without netvm pose a problem?

Preserving the IP (so it will stay the same after switching netvm) - not a problem. Keeping the IP set in the VM while it doesn't have netvm - not so easy, because there is no network interface there, so no place to set the IP on.

Anyway, I've just implemented this (for Qubes 4.0). The VM IP can be set to any value. This is the IP really used for routing etc, so can't be duplicated. There is also another feature #1143 for hiding the "real" IP (possibly set by the user using feature discussed here) from the VM. So, VM can see any IP as its own, but it's got NATed in its netvm to the "real" one. This "fake" IP can be duplicated without an issue.