Open trueriver opened 6 years ago
Update: this is not specific to HVMs, it seems to be so for all my AppVMs that use the network. However it is in the HVMs that it particuluarly matters as that is where users most often need to enter the relevant network settings manually.
Title changed to reflect this
Unless you want to access other VMs (https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes), indeed 255.255.255.0 will work. Otherwise 255.255.255.255 should be used, plus a specific route for the gateway. On Linux it would be (assuming 10.137.0.1 gateway address):
ip route add 10.137.0.1/32 dev eth0
ip route add default via 10.137.0.1
That is fine for an existing VM with a terminal or console.
It does not work when the VM is very precise about what it wants; one example is the Debian Net Install iso. It simply refuses to accept the netmask as given.
Secondly, as you say, it also does not work for the case where I am setting up an HVM to be a database server for other VMs, which is my current use-case. I had already visited the link you give, and got off-track due the the docs saying "put in the netmask from Setting" or words to that effect. You could use a dedicated pair of ip route commands for each possible destination on 10.137.0.0/16 I suppose...
And thirdly, though I personally have done the equivalent on windows, the ROUTE command if I remember correctly, I think many people instaling a Windows iso in the HVM will be totally perplexed.
But even with the documents updated, I would still question why it is useful to display a value that only works with additional expert knowledge. I am curious why you choose to have it displayed in Settings at all if it is always going to be 255.255.255.255 ?
I am sure you have a good reason, no doubt it is more secure somehow. Except when the security stops the use-case working.
In the meantime the docs need to be put into sync with what is currently displayed. I am glad Andrew has already added the tag :)
In the meantime the docs need to be put into sync with what is currently displayed. I am glad Andrew has already added the tag :)
:slightly_smiling_face:
You might be the one in the best position to help improve the docs. Please consider submitting a pull request:
Yes, I noticed the help wanted tag ;)
I probably can't do it this week, but will do it sometime this month. Befroe writing it up I would prefer to understand what the devs thought process is in publishing a netmask that is not directly usable in the usual way?
I understand how this netmask makes the VM slightly more secure, but effectively it is not a subnet mask at all but is saying don't use subnetting. So why not remove it entirely from the display? Is there a case where any R4.0 Qube displays a netmask that is anything other than this?
On my system all network attached Qubes show the same /32 netmask, and all non-network Qubes show it empty and greyed out.
I am still asking the devs to consider removing the display of this netmask as being less misleading to the newcomer. (The Qubes Guru will cope whether it is altered or not)
Is this a relic from R3 or earlier? Did Qubes used to use conventional subnet networking?
Im having this issue on 4.0.1 , even when i use 255.255.255.0 and yes it will proceed the installation of the distro (look at #5198 for more details) But no interent connection inside the empty template not based on qube.
Screenshot for connection info within debian distro:
Screenshot for connection info from qube manager
Does pinging some host using IP work? Can you ping the gateway?
Does pinging some host using IP work? Can you ping the gateway?
Yep
logs might useful:
/var/log/xen/console/guest-nameofdebainnontemplate-dm.log:
on the above log , i have deleted too many of:
Can't convert keycode f8 to scancode
just to make the logs simple as possible
Does pinging some host using IP work? Can you ping the gateway?
Yep
Ok, so connection to sys-firewall (or whatever you have chosen there) works. How about some internet IP, like 8.8.8.8? Try also pinging by name (like qubes-os.org
).
Ok, so connection to sys-firewall (or whatever you have chosen there) works. How about some internet IP, like 8.8.8.8? Try also pinging by name (like qubes-os.org).
Yes worked as well. So i think what happened is after i entered virtualdns manually after finishing the OS installation (instead of blank) then (that what makes it worked) restarted the VM it got connected to the internet.
Installing OS outside of templates bit tricky , no new user going to know it.
Qubes OS version:
R4.0
Affected component(s):
Settings
Steps to reproduce the behavior:
Create a new HVM and boot from an iso (I used the latest Debian net install)
Expected behavior:
Netmask shows a usable value, probably 255.255.255.0 which works for me
Actual behavior:
Netmask shows an unusable value of 255.255.255.255 making the gateway unreachable if you use this in the HVM network settings
General notes:
Note the ip addresses of the new machine and of the gateway seem to be OK, once the netmask is corrected the netwokring comes up nicely
Related issues: