Combination of OpenBSD sys-net + MirageFW

I’m using this for my OpenBSD VPN NAT

pass in proto { udp tcp } from wg1:network to any port domain rdr-to 9.9.9.9 port domain
2 Likes

@palainp Sorry for the delay, I don’t have a GitHub account but thank you. With the help from @solene in the message below I was able to confirm that it also works for DNS.
Mirage firewall with this setup has trouble keeping up with the packets reaching 100% CPU, is it likely to be because of the logs?

Yes probably as it outputs a couple of lines for each packet. You may try the PR in the mirage repository which avoids printing so much.

And thanks for the testbed!

1 Like

It was, thank you! :slight_smile:
(This message was sent using HardenedBSD + MirageFW)

4 Likes

@palainp MirageFW v0.9.2 prevents domains from starting up:

[INFO] [net-xen backend] Frontend asked to close network device dom:25/vif:0
[ERROR] [dispatcher] uncaught exception trying to send to client:
                     Failure("mirage_xen_gnttab_map: failed")
[ERROR] [dispatcher] uncaught exception trying to send to client:
                     Failure("mirage_xen_gnttab_map: failed")
[ERROR] [dispatcher] uncaught exception trying to send to client:
                     Failure("mirage_xen_gnttab_map: failed")
[ERROR] [dispatcher] uncaught exception trying to send to client:
                     Failure("mirage_xen_gnttab_map: failed")
[ERROR] [dispatcher] uncaught exception trying to send to client:
                     Failure("mirage_xen_gnttab_map: failed")
[INFO] [dispatcher] Client 24 (IP: 10.138.10.177) ready
[INFO] [ethernet] Connected Ethernet interface fe:ff:ff:ff:ff:ff
[INFO] [dispatcher] New firewall rules for 10.138.10.177
0   any   accept
[dom24:10.138.10.177] [client_eth] Waiting for old client dom25:10.138.10.177 to go away before accepting new one
[ERROR] [dispatcher] uncaught exception trying to send to client:
                     Failure("mirage_xen_gnttab_map: failed")
[ERROR] [dispatcher] uncaught exception trying to send to client:
                     Failure("mirage_xen_gnttab_map: failed")
[ERROR] [dispatcher] uncaught exception trying to send to client:
                     Failure("mirage_xen_gnttab_map: failed")
[ERROR] [dispatcher] uncaught exception trying to send to client:
                     Failure("mirage_xen_gnttab_map: failed")
[ERROR] [dispatcher] uncaught exception trying to send to client:
                     Failure("mirage_xen_gnttab_map: failed")
[ERROR] [dispatcher] uncaught exception trying to send to client:
                     Failure("mirage_xen_gnttab_map: failed")
[ERROR] [dispatcher] uncaught exception trying to send to client:
                     Failure("mirage_xen_gnttab_map: failed")
[ERROR] [dispatcher] uncaught exception trying to send to client:
                     Failure("mirage_xen_gnttab_map: failed")
[ERROR] [dispatcher] uncaught exception trying to send to client:
                     Failure("mirage_xen_gnttab_map: failed")
[ERROR] [dispatcher] uncaught exception trying to send to client:
                     Failure("mirage_xen_gnttab_map: failed")
[ERROR] [dispatcher] uncaught exception trying to send to client:
                     Failure("mirage_xen_gnttab_map: failed")
1 Like

Dear @nalea, that sounds bad :frowning:
Unfortunately I cannot reproduce the issue locally. I don’t use *BSD as sys-net, and not that setup right now, so I can only try out with 2 AppVM connected but I can’t test connexion to external destination.

Would you mind to explain (here or in PM) what was the setup when that comes into the logs? This should be printed when the unikernel can’t write pages to a client VM (here either a real client or the BSD AppVM connected as a client) at qubes-mirage-firewall/dispatcher.ml at 923719f306ad653060dd5c1395e20495839ef7d0 · mirage/qubes-mirage-firewall · GitHub, when the Xen mapping fails. So I wonder if that is caused by a shutdown and the unikernel has not noticed it, or a deeper Xen communication process that failed, or something else.

Your two first lines should be (when everythiong goes right) something like:

[INFO] [net-xen backend] Frontend asked to close network device dom:25/vif:0
[INFO] [dispatcher] client {domid=25;device_id=0} has gone

Then a lot of lines corresponding to a normal client connexion.

I sent you a PM since I’m not sure this is reproducible :upside_down_face: