networking in proxyVM

[Zrubi]

Qubes OS version (e.g., R3.1):

3.1 (testing repo enabled)

Affected TemplateVMs (e.g., fedora-23, if applicable):

fedora 23

---

Expected behavior:

If I change one firewallVM's netVM the internal IP addresses and routing table are changing according to the new netVMs setting

Actual behavior:

The default route not changing, remaining related to the first assigned netVM. Even after I change it's netVM.

Steps to reproduce the behavior:

• Start a firewallVM assignet to a netVM
• change the netvm to another one
• check your routing table.

General notes:

Environment:
I have separated netvms: WiFi, Ethernet
I have several firevallVMs each connected to one of the netvms

It was working as expected before - but not sure which update has broke it.

---

Related issues:

[marmarek]

Do you get any errors during the switch? Especially in firewallvm syslog.

[marmarek]

Do you get any errors during the switch? Especially in firewallvm syslog.

[Zrubi]

just checked dmesg before.. now I found one in syslog:

systemd-udevd[4279]: Process '/usr/lib/qubes/setup-ip' failed with exit code 1.

The sorroundings:

Jun 15 10:25:12 Home-VPN NetworkManager[509]: (eth0): failed to find device 23 'eth0' with udev
Jun 15 10:25:12 Home-VPN NetworkManager[509]: (eth0): new Ethernet device (carrier: OFF, driver: 'vif', ifindex: 23)
Jun 15 10:25:12 Home-VPN systemd-udevd[4279]: Process '/usr/lib/qubes/setup-ip' failed with exit code 1.
Jun 15 10:25:12 Home-VPN NetworkManager[509]: (eth0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Jun 15 10:25:12 Home-VPN NetworkManager[509]: (eth0): link connected
Jun 15 10:25:12 Home-VPN NetworkManager[509]: (eth0): device state change: unavailable -> disconnected (reason 'none') [20 30 0]
Jun 15 10:25:12 Home-VPN NetworkManager[509]: Auto-activating connection 'VM uplink eth0'.
Jun 15 10:25:12 Home-VPN NetworkManager[509]: (eth0): Activation: starting connection 'VM uplink eth0' (de85f79b-8c3d-405f-a652-cb4c10b4f9ef)
Jun 15 10:25:12 Home-VPN NetworkManager[509]: (eth0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Jun 15 10:25:12 Home-VPN NetworkManager[509]: NetworkManager state is now CONNECTING

[Zrubi]

just checked dmesg before.. now I found one in syslog:

systemd-udevd[4279]: Process '/usr/lib/qubes/setup-ip' failed with exit code 1.

The sorroundings:

Jun 15 10:25:12 Home-VPN NetworkManager[509]: (eth0): failed to find device 23 'eth0' with udev
Jun 15 10:25:12 Home-VPN NetworkManager[509]: (eth0): new Ethernet device (carrier: OFF, driver: 'vif', ifindex: 23)
Jun 15 10:25:12 Home-VPN systemd-udevd[4279]: Process '/usr/lib/qubes/setup-ip' failed with exit code 1.
Jun 15 10:25:12 Home-VPN NetworkManager[509]: (eth0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Jun 15 10:25:12 Home-VPN NetworkManager[509]: (eth0): link connected
Jun 15 10:25:12 Home-VPN NetworkManager[509]: (eth0): device state change: unavailable -> disconnected (reason 'none') [20 30 0]
Jun 15 10:25:12 Home-VPN NetworkManager[509]: Auto-activating connection 'VM uplink eth0'.
Jun 15 10:25:12 Home-VPN NetworkManager[509]: (eth0): Activation: starting connection 'VM uplink eth0' (de85f79b-8c3d-405f-a652-cb4c10b4f9ef)
Jun 15 10:25:12 Home-VPN NetworkManager[509]: (eth0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Jun 15 10:25:12 Home-VPN NetworkManager[509]: NetworkManager state is now CONNECTING

[marmarek]

Ah, you have NetworkManager in that FirewallVM. Try restarting it - maybe it doesn't notice updated settings for eth0.

[marmarek]

Ah, you have NetworkManager in that FirewallVM. Try restarting it - maybe it doesn't notice updated settings for eth0.

[Zrubi]

You mean I should restart after every NetVM change?

I rebooted to see if it's solve this. And yes after reboot (maybe restarting the NM would be enough) it is working - but just until I change the netvm again...

[Zrubi]

You mean I should restart after every NetVM change?

I rebooted to see if it's solve this. And yes after reboot (maybe restarting the NM would be enough) it is working - but just until I change the netvm again...

[marmarek]

Yes, restart (or better try reload) NetworkManager after NetVM change. If that help, will add this to the script to handle it automatically.

[marmarek]

Yes, restart (or better try reload) NetworkManager after NetVM change. If that help, will add this to the script to handle it automatically.

[Zrubi]

reload not helps.
restart after the new netvm has no effect.

However I found out if I following this procedure:

• set the netvm to none
• restart (reload not enough) NM
• set the new netvm

Then I got the proper routing.

[Zrubi]

reload not helps.
restart after the new netvm has no effect.

However I found out if I following this procedure:

• set the netvm to none
• restart (reload not enough) NM
• set the new netvm

Then I got the proper routing.

[marmarek]

Doesn't look like a good idea to do that automatically...
Maybe it's about when the configuration is modified. Take a look at /usr/lib/qubes/setup-ip and try stopping NM just before writing config and start just after.

[marmarek]

Doesn't look like a good idea to do that automatically...
Maybe it's about when the configuration is modified. Take a look at /usr/lib/qubes/setup-ip and try stopping NM just before writing config and start just after.

[Zrubi]

I found the solution (in the nmcli man page)

NetworkManager does not monitor changes to connection files by default. So you need to use this command in order to tell NetworkManager to re-read the connection profiles from disk when a change was made to them. However, the auto-loading feature can be enabled and then NetworkManager will reload connection files any time they change (monitor-connection-files=true in NetworkManager.conf(5)).

extending the main NM config with the parameter above solved this problem. :)

(However still not know when and where was changed about these)

[Zrubi]

I found the solution (in the nmcli man page)

NetworkManager does not monitor changes to connection files by default. So you need to use this command in order to tell NetworkManager to re-read the connection profiles from disk when a change was made to them. However, the auto-loading feature can be enabled and then NetworkManager will reload connection files any time they change (monitor-connection-files=true in NetworkManager.conf(5)).

extending the main NM config with the parameter above solved this problem. :)

(However still not know when and where was changed about these)

[Zrubi]

This error message is still there:
systemd-udevd[4279]: Process '/usr/lib/qubes/setup-ip' failed with exit code 1.

So it seems not related to this issue.

[Zrubi]

This error message is still there:
systemd-udevd[4279]: Process '/usr/lib/qubes/setup-ip' failed with exit code 1.

So it seems not related to this issue.

[marmarek]

Maybe you didn't used NM before? Or maybe since this commit: QubesOS/qubes-core-agent-linux@d23f3d8

[marmarek]

Maybe you didn't used NM before? Or maybe since this commit: QubesOS/qubes-core-agent-linux@d23f3d8

[unman]

@marmarek
I've tested this today and cant reproduce the error, with NM running or not.
Everything works as expected.
Can we close this?

[unman]

@marmarek
I've tested this today and cant reproduce the error, with NM running or not.
Everything works as expected.
Can we close this?

[andrewdavidwong]

@Zrubi, are you still experiencing this issue?

[andrewdavidwong]

@Zrubi, are you still experiencing this issue?

[Zrubi]

On 01/12/2017 05:36 AM, Andrew David Wong wrote: @Zrubi <https://github.com/Zrubi>, are you still experiencing this issue?

I do not have any 3.1 instance, so I can't even test it. This issue was not affect 3.2 - what I'm using on all of my Qubes boxes.

…

-- Zrubi

[Zrubi]

On 01/12/2017 05:36 AM, Andrew David Wong wrote: @Zrubi <https://github.com/Zrubi>, are you still experiencing this issue?

I do not have any 3.1 instance, so I can't even test it. This issue was not affect 3.2 - what I'm using on all of my Qubes boxes.

…

-- Zrubi

[andrewdavidwong]

Ok, let's close this then.

[andrewdavidwong]

Ok, let's close this then.