Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upoptional static IP addresses #1477
Comments
marmarek
added
enhancement
C: core
P: major
release-notes
labels
Jan 6, 2016
marmarek
added this to the Release 4.0 milestone
Jan 6, 2016
adrelanos
referenced this issue
Feb 28, 2016
Closed
VMs with Whonix-Tor networking timeout and do not recover #1779
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
john-david-r-smith
May 18, 2016
in this context, i want to add what i would want of static ips.
- 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).
- 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)
- if a vm has no netvm, it keeps its static ip
john-david-r-smith
commented
May 18, 2016
|
in this context, i want to add what i would want of static ips.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
May 19, 2016
Member
- 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.
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
john-david-r-smith
May 19, 2016
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?
john-david-r-smith
commented
May 19, 2016
|
case A) case B) 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? |
added a commit
that referenced
this issue
May 31, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Oct 31, 2016
Member
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.
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. |
adrelanos commentedDec 1, 2015
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
.dconfig snippet mechanisms.)In Whonix hidden services instructions there is a chapter that suggests to torrc.
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 https://github.com/QubesOS/qubes-issues/issues/1143#issuecomment-136128886.)]