I need to add some static routes since I'm using a network with different GWs. For that reason I've tried to add some static routes through the NetworkManager which maps all the configuration into a file called qubes-uplink-eth0 . Strangely and since this file is within the private disk image, one would expect that the changes are be preserved after a reboot, unfortunately this has not been the case. Everytime there's a reboot the file gets overwritten somehow.
Does anyone know if there's a way to preserve static routes on Qubes or is this simply a limitation?
Thank you
----
Sent using GuerrillaMail.com
Block or report abuse: https://www.guerrillamail.com/abuse/?a=UFR2AB5NVqcQmh2U93EQdRjCStifx8dDiadNcQ%3D%3D
Does anyone knows how to set static routes persistently into the sys-firewall?
Thanks
So is there a way to static add this routes via the Network Manager ensuring they are preserved at each boot?
Does anyone knows how to achieve this on Qubes?
Thanks
ls /etc/NetworkManager/system-connections
131205 lrwxrwxrwx 1 root root 32 Oct 17 21:17 /etc/NetworkManager/system-connections -> /rw/config/NM-system-connections/
The /dev/xvdb is properly mounted on /rw :
/dev/xvdb on /rw type ext4 (rw,relatime,discard,data=ordered)
I don't have a /etc/system directory on my system, are you referring to the unit files?
For the sys-firewall I'm using the default template - > fedora-23
When I set the routes by hand via NetworkManager they are reflected on the qubes-uplink-eth0 file:
(...)
[ipv4]
address1=10.137.1.8/32,10.137.1.1
dns=10.137.1.1;10.137.1.254;
dns-search=
may-fail=false
method=manual
never-default=true
route1=192.168.0.0/16,10.137.1.1
route2=172.16.0.0/16,10.137.1.1
#---EOF---
The file before the sys-firewall is rebooted has the following checksum and md5sum:
2551335477 425 qubes-uplink-eth0
83b37a6b68007838efb1e9e9fbc841f4 qubes-uplink-eth0
As soon as the sys-firewall is booted the file with the NW configuration is overwritten :
[ipv4]
method=manual
may-fail=false
dns=10.137.1.1;10.137.1.254
addresses1=10.137.1.8;32;10.137.1.1
#---EOF---
As you can see the configuration was not preserved.
Therefore something is clearly overwritten the NM configuration, the problem is to know what and how to avoid it, preserving the NM config.
So in short, I cannot tell what process have been changing the NM configuration at every boot. It would be great if someone from the Qubes support would be able to shed some light on this.
Does anyone knows how to achieve this on Qubes?
----
Sent using Guerrillamail.com
It seems that this ML is only breathing, beacuse of the individual effort of its users. To the date, no one from the official team (https://www.qubes-os.org/team/) was able to chip in or give any answer.
This is a bad start for this project, lack of support is one of the reasons why some projects are not successful..
And to think I was about to give some donations for this project....
I could have set the file with the immutable flag on, I could have created a rc.local script...etc
I could have done many workarounds, but these would be, as the name implies, workarounds. What I want to know is to know why the static routes on the NM configuration are being overwritten and how to avoid that.
So far not a single soul from the qubes project has mentioned a single word about this and this is simply unacceptable! This mailing list is been abandoned!
Point proven - all the contacts for the ML and the help section were removed from the main site. The page https://www.qubes-os.org/help/ is now redirected to https://www.qubes-os.org/doc/ .
Is this project over before it has taken off?!?
I didn't mean to be rude/aggressive/impolite/disrespectful in any way nor making inflammatory or baseless accusations.
So my sincere apologies for that.
Regarding the Qubes main page, I was not aware of this discussion. I was simply baffled by the lack of the 'help' section and erroneous concluded (based on this and the lack of reply from anyone from the official team) that the ML is no longer supported.
Again my apologies for that.
As for the issue it was outlined in details in this thread, (and I did respond to JJ with the detailed description of the issue, which I'm quoting below):
----
I was not able to put this to work via the network manager,since if I opt to choose eth0 this the connection will not be activated. And create a dedicated virtual interface just for this purpose its a little overkill.
Therefore I followed your second suggestion and added the routes manually in the qubes-ip-change-hook . Although I don't think this is a very elegant solution, at least the routes were persistent added in each reboot, which solves my issue.
Thank you once again.