I actually use Portmaster installed as a template, but in an immutable way. All virtual machines based on that template use the firewall immutably. I don’t use any DNS services included with Portmaster because they are public DNS servers. I have it configured without DNS; I only use it as a firewall to filter traffic. I don’t find its SPN privacy model useful because, in the past, the DNS servers it includes by default, such as Cloudflare (1.1.1.1) and others, were infected, making it a gateway for cyberattacks. Regards.
Portmaster and Rethink are two default installed apps.
Portmaster has an option to add custome DNS and sort on reqyuired priority. Also,it has an option to overwrite local host settings.
Im paying for ControlD services…and…im using secure DNS.
Hope makes sense.
Thank you for your message. After reviewing the Rethink website, it looks promising. Could you share your procedure for installing and integrating it with Portmaster? Is it possible to use Rethink for free in any way?
this has gone off topic a bit into dns resolvers, but I looked at Rethink and found it to be android focused and as this is an openBSD post, it doesn’t seem to fit openBSD well. Unbound, imo fits better for security and minimalism for an OpenBSD sys-net, with its native recursive resolution with DNSSEC, minimal and full open-source, while RethinkDNS is more mobile-oriented with unnecessary bloat for an openBSD sys-net. I also can’t see much use for Portmaster which seems to have no proven compatibility with openBSD and imho seems inferior to the openBSD fw which when configured with unbound (and / or DNS_crypt ) seem to be more battle-tested and reliable than these suspicious mobile oriented new gimmicks.
I should add that I am also against list-based blockers, its a whack-a-mole approach and its to easy for an attacker, as they can easily create infinite variables to bypass online block-lists. It always seemed to me as a false sense of security ( I have all the lists so I am safe)
> * Follow the instructions to install the sets it’s on cd0
> * You don’t need game76.tgz and x.tgz packages deselect them with -game* and -x*
if you want a minimal setup you can actually remove all sets except for base!
You can create a dns qube with pfsense or open.(or other)bsd’s and run unbound with your own configs if you don’t want to rely on any external dns, just use the same pf.conf @unman gave and put the ip of the dns qube,.
Interesting opinion, but I must clarify that Portmaster only works in the destination qube, something like the last barrier, nothing more; it cannot be integrated into a network qube to filter traffic.
My install did not ask for gateway or DNS servers after setting up em0 with dhcp, but auto-assigned DNS from dhcp. Browser in AppVM works as expected via sys-mirage, but DNS used is not 9.9.9.9
If I edit resolv.conf with my qubes dns and add my gateway to /etc/mygate, I lose all connection in sys-net-openbsd with ‘xnf0: tx stuck’ errors.
sysctl.conf and pf.conf are edited, kernelopts are added to sys-mirage - I’m not understanding, how does this thing work?
It’s quite unclear what you have done - “my install” - what install?
If you chose em0 with dhcp, then of course DNS will be allocated
automatically. What else would set quad-9?
What values did you set for /etc/mygate?
What values did you set for resoilv.conf?
For a general question like “how does this thing work?”, it’s very
difficult to answer without some idea of your level of knowledge, of
Qubes and of *BSD.
On a very high level, BSD can be used to provide sys-net, instead of
one of the Linux distros included in Qubes.
To do this you need to create a BSD qube, attach the network hardware,
and configure it as a gateway device. The other interface is attached to
a firewall and other qubes are attached to the same firewall.
The firewall is configured to pass traffic between the qubes and the BSD
gateway.
If you meant something different by your question, perhaps you could be
clearer.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Thanks unman, yes my apologies - I was writing as though I was part of the conversation already. “My install” was referring to my experience installing and setting up OpenBSD v7.8 as per thread instructions. I re-read through the whole thread and have a very similar experience to connor.blane, so the responses to them applied to my case. I was replacing my DHCP allocated DNS in /etc/resolv.conf with Qubes virtual DNS 10.139.1.1, 10.139.1.2 as per instructions, but I see that is not correct as you previously pointed out.
I now have a functioning OpenBSD sys-net running via sys-mirage from (mostly) following the instructions, the only problem I have now is that the pf.conf rules to redirect DNS queries to 9.9.9.9 are not being followed. I have /etc/hostname.em0 set to inet autoconf, does this setting override /etc/resolv.conf? I have set /etc/dhcpleased.conf to interface em0 { ignore dns } and /etc/resolv.conf to nameserver 9.9.9.9 but it is still routing DNS via my router settings.
My knowledge of *BSD is close to zero, as may be evident.
This turned out to be a PEBKAC issue - I hadn’t realized Quad9 was utilizing my nearest Anycast server (duh). dhcpleased.conf was doing its job preventing overwriting of resolv.conf and pf.conf rules were always working.
Thanks for assistance and @qEawma5f for the guide, perhaps it could be updated to prevent confusion regarding Qubes DNS virtual servers?
I believe this is missing a setup for clockvm. This guide will leave sys-net as the clockvm, leading to there not being proper time sync due to it never booting. AFAIK sys-net-openbsd can’t be the clockvm since it has no qubes tools. So a sys-time needs to be set up.
This is pretty easy. Just create a named disposable sys-time from your preferred template and set qubes-prefs clockvm sys-time. I recommend kicksecure since then time is derived from sdwdate rather than ntp. See this link for a comparison. It works out of the box.
Probably obvious to everyone but me, but if, with this set-up, all qubes are receiving network from sys-firewall, including sys-net-openbsd, what purpose does sys-net-openbsd serve? ie. where does sys-net-openbsd provide internet (nowhere, seemingly?) I may never try this until I understand everything better, but I imagine there’s other clueless users like myself who have no idea what the (probably obvious) answer to this question is.
The *BSD sys-net has a NIC attached, and is therefore able to connect to
the external network.
In order for Qubes networking to work in this situation, you have to use
sys-firewall as an intermediary. You can use this approach for any HVM,
including Windows qube.
sys-net-openbsd has netvm set to sys-firewall, and forwards network
traffic to sys-firewall.
sys-firewall has special rules that handle forwarding traffic between attached qubes.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Thanks for your response! Bare with me and allow me to oversimplify to make sure I got it right. Basically, in ‘caveman’ terms, the network manager or network devices are attached to sys-net-openbsd so it does have internet, and it gives internet to sys-firewall even though it is not set as sys-net → sys-firewall → qubes in some magical manner, but the sys-firewall rules still apply to our sys-net-openbsd… correct?
Usually after a suspend, but sometimes in the middle of use, i find this sys-net-bsd completely unresponsive, the cpu balloons to 98% and the only thing i can do is kill it and restart. This happens a few times a day.
I tried to update the kernel, firmware etc… but it continues. I increased ram and: sysctl machdep.lidaction=0
The WIFI driver is for the intel: iwm0, but as the whole VM freezes I suspect this is something on the xen / Qubes side. The build is exactly as the op.
i can see nothing in dmesg / var/log/messages just the usual rebooting messages.( on the Bsd side)
I use iwx. If I suspend, sys-net-openbsd is always frozen upon waking up. So I always shut it down before suspend. I’m planning on adding a suspend hook so that this works automatically.