loss of connectivity on upstream VM restart

[xaki23]

when the upstream VM of a mirage firewall gets restarted, the mfw doesnt recover from that and needs to be restarted as well.

repro steps:

• set up a network chain like internet <...> linuxA <-> miragefw <-> linuxB
• ping something external from linuxB
• qvm-kill linuxA (or run poweroff inside it)
• qvm-start linuxA
• note even after linuxA is up again, linuxB will not be able to reach across the chain
• restart miragefw
• connections work again

a linux FW in the middle position will recover from temporary loss of its upstream interface. there doesnt seem to be anything relevant being logged on the mfw console.

[rootnoob]

This is not just an issue with upstream vm-restart, mirage-firewall v0.8.2 cannot handle change of upstream VM. Try: qvm-prefs mirage netvm x

It will take longer than usual to complete the command, but no error is given (and qvm-prefs netvm mirage displays the netvm change). However, any downstream VMs attached to mirage will no longer have connectivity - the netvm change has not completed succesfully. As above, this requires restart.

Also, see issue: https://github.com/mirage/qubes-mirage-firewall/issues/157 (Downstream VMs cannot detach properly from mirage v0.8.2)

As both #156 and #157 was described in #59 many versions ago, it could be a regression, so I've mentioned them there: https://github.com/mirage/qubes-mirage-firewall/issues/59

[palainp]

Thanks for the reports!

With qvm-prefs mirage netvm x I can see in the logs a line with INF [qubes.db] got update: "/qubes-gateway" = "10.137.0.x" (this is good but nothing is done to deal with that) which doesn't show up when (nothing does) when I run qvm-kill x (it's not as good but it can be improved :) ).

I think for both cases we'll have to add something to monitor Xenstore for uplink as is currently the case for clients VM and add the code to dynamically change the uplink interface (it doesn't seem so trivial at the moment, I'll have to think about it a bit :) ).

[palainp]

In the working process for adding OpenBSD as a possible netvm, I've been working on dynamic netvm management. @xaki23, @rootnoob would you mind to try out the current head of https://github.com/palainp/qubes-mirage-firewall/tree/common-vif ? Sorry I haven't updated the hashsum so far (and not sure build_with_docker without docker cache will still compiles as notset.fr is down).

[palainp]

Update: I still have some issues, and I'm not sure how to solve them :( If the uplink AppVM is stopped we have no qubesDB updates (probably this could be something to check into the mirage-xen related code), any the same if we manually set netvm to none. Also, I'm having trouble monitoring only our gateway IP in qubesDB (I currently have an update for each keys modifications). So I have the following:

• The current patch does permit to change the netvm AppVM from one to another. And this is the same if we start qmf with netvm=none, and change our mind later.
• The current patch does not permit to directly fix the current issue (an uplink restart will be considered as a "same IP as before" and does not reconnect uplink). That is the same situation when swaping between an uplink, none and the same uplink AppVM.

But with the current patch, in the openning situation, it's possible to do (without the need to restart qmf):

[CRASH OF UPLINK VM]
qvm-prefs qmf netvm [ANOTHER APPVM]
qvm-prefs qmf netvm [UPLINK VM]

[palainp]

Sorry for the daly, this issue should be fixed by #178 which has been merged. @rootnoob @xaki23 this has been released yet, but in the meantime you should be able to compile and try out the latest version :)

[palainp]

Thank you for the report, this issue should have been fixed since release 0.9.0. Please reopen if this is not the case.