For those using Mirage-firewall, the official build for 0.8.0 has been released, including support for PVH and better memory management. The official builds are available at: Releases · mirage/qubes-mirage-firewall · GitHub, and information on building and installation is here: https://github.com/mirage/qubes-mirage-firewall.
I started testing it but I haven’t run it for too long, so I can’t speak to performance and stability yet.
Very good news! 
I’m just eagerly waiting for when they add it to the qubes community repos since that’s the only blocker for me (and many others!) using it.
Yeah, that would be great.
In the meantime, I can report that stability seems perfectly fine and, while I have not run any scientific performance benchmarks, it seems to work well for my network access needs. There was what seems to be a memory leak in the older version, which now seems to be either fixed or less noticeable.
This.
I built it and tried to use it, but my OpenVPN qube network always go down and up again after a few minutes for some reason. Anyone having the same issue?
Same here. Mirage firewall works fine if integrated with a non-openvpn qube. The minute I attached it to a vpn qube (@tasket type) the connection just cycled up and down and the qube became unusable.
I’d also like to hear more about this once it’s in community repo.
@DVM @qub411 can you please clarify for which version of mirage-firewall this issue is present?
I have experienced similar VPN & tunneling stability issues with V0.7, V0.7.1, however adjusting the RAM/memory reduced the occurences hence I believe it to be caused by the same memory-leak issue mentioned by @flavio .
I’m also having this issue. 0.8.0, Mullvad wireguard VPN, working except with MullvadVPN qube, then I just get no network response.
Hmm… Wireguard VPN… doesn’t it use UDP? If so, the mirage firewall Qube may not be configured to pass UDP from the world back into your VPN Qube. Did you try adding a rule to allow for that traffic?
Long-time Mirage user and advocate here,
I’ve never had an issue with firewall connectivity, and the previous 2020 release ran fine throughout its life; but with this new release the firewall after my Wireguard VM just silently crashes on occasion, leaving a gap in my network stack. On Qubes Manager that firewall is shown as shut off and I have to manually start it.
I have too few data points to be sure, but the crashing doesn’t seem correlated with network load as they have so far occured at low loads. Sometimes the crashes seem to affect dom0, which is very concerning.
I hope someone working on Mirage reads this since I don’t have a Github account to let them know directly.
Possibly linked to my issue above:
Thread on qubes-devel on including Mirage-firewall to the Qubes community repos:
https://groups.google.com/g/qubes-devel/c/ZcR01kc3dz4
The Robur collective actually developed reproducible builds for MirageOS unikernels: Job qubes-firewall
This conducts a build on a daily basis with the current HEAD of qubes-mirage-firewall and the latest (to opam, the OCaml package manager) released packages that it depends on. It would be great if we could push whenever the binary is updated a new release to all QubesOS users, thus:
- how should it be packaged (at the moment, it is the binary (virtual machine image))?
- could that be integrated into the QubesOS community repository?
Interesting. Can you describe that situation a bit more in detail? Any idea how to debug that kind of crashes?
So far, I’ve had one unexpected shutdown of my mirage-firewall net-vm. It was after a network outage this morning and I do have the same error message that is mentioned in that issue:
Fatal error: out of memory
Aborted
Solo5: solo5_abort() called
Update (5d): Another unexpected mirage-firewall “out of memory” shutdown; I didn’t notice a network outage this though.
Nice to see some fresh conversation going on about this.
Glad that Demi is in favor of including Mirage to the QubesOS repos, so that users wouldn’t have to export unikernel os from AppVM to dom0.
However, can someone talk more about Demi’s reservation about the “speed” ?
I hope so too, and I would like it to become fast enough to be the
default.
Also, Holger Levsen seems to argue that,
On slow computers (eg x230) it’s not only slow
but might also be using one cpu 100%
Is this true?
Check this issue it has some illustrative benchmarks:
I can confirm I had many of these crashes. Since increasing the memory assigned to the mirage-firewall VM, I have had no more crashes.
After suffering tens more crashes it seems as though the issue with dom0 was a one-time coincidence. Debug it using your typical Linux debugging skills with a bit of Qubes knowledge?
I run two Mirages, and it’s only the second one behind my Wireguard VM that consistently crashed, even though the loads the two experienced were virtually identical (not the routing though).
Based on consistent reports of Mirage crashes after network outage and the lack of crashes with my sys-net Mirage despite the fact I frequently remove my ethernet cable, I suspect my crashes had something to do with Wireguard’s quirks.
Also, increasing memory ended the crashes.