For active Mirage users out here, how is the stability on Qubes 4.3.2?
I would love to read about your experiences since I feel like its benefits are underrated.
For active Mirage users out here, how is the stability on Qubes 4.3.2?
I would love to read about your experiences since I feel like its benefits are underrated.
Actually two users reported a bandwidth drop after some hours running (see Dramatic bandwidth restrictions after some time · Issue #233 · mirage/qubes-mirage-firewall · GitHub ). As I said in the issue, I think the situation is better with the current head, but I’ve not yet released it because I had no feedback yet and I’d prefer to not release based only on my laptop/tests.
Thanks for the reply. I hope others who have successfully tested Mirage with the current head will post their feedback to help speed up the release. I’m going to test it myself as well.
The only problem I had was after update and restart of sys-net qube Mirage firewall had to be restarted manually or there was no internet. I’ve switched to OpenBSD for sys-net since then.
Thanks for the reply. If there are no other issues, i’m totally fine with a quick manual restart.
I use mirage as my main firewall for last year. Would not recommend on wifi until we build some automation to restart it on connectivity loss, but it is rock solid on wired connection.
I’m really eager to get your feedback on the current head of the github repository since I’ve applied the generic segmentation offload and I don’t have anymore an openbsd sys-net. So I’m unsure about the status of how openbsd behave with those big frames, and there is currently no re-segmentation, so if that doesn’t work (or work badly), I’d fix it before release ![]()
If you don’t mind to test it out, you can use the podman compilation from source instructions, or I can provide a compiled unikernel as you prefer.
About the netvm issues (connection lost after sys-net restart), I don’t have clues on how to fix that yet, as the unikernel receive an event something has changed in qubesDB, but the netvm IP is the same so it believe that there is nothing to do on that side. And I don’t want to disconnect/reconnect to netvm on each event ![]()
About the wifi issues, I don’t have them, but I restart my laptop often, so that may be the reason ![]()
I tested the current head compiled via Podman using WIFI only. So far, hours of torrenting, sleep wakeups, leaving it on overnight, WiFi radio off and on, etc, and I had no connectivity issues at all or any speed difference compared to my Debian sys-firewall. The only minor issue is that restarting my (Debian) sys-net alone still breaks connectivity and requires a Mirage restart as mentioned by others.
I never restart a running sys-net after updates and wait until I shut down, but it could be an issue for others. And note that I only tested with VPN/Tor, so i don’t exclude that much higher non-VPN/Tor speeds could still cause issues for others.