What happens if you run qvm-pause sys-net-openbsd before doing suspend and qvm-unpause sys-net-openbsd on unsuspend? Shot in the dark, but curious.
1 Like
If you want to randomize the mac:
add
lladr random
up
to the hostname.*** files in /etc/
To randomize hostname:
#!/bin/sh
set -- $(
awk '
BEGIN { srand() }
{
if (rand() * NR < 1) a = $0
if (rand() * NR < 1) b = $0
}
END { print a "-" b }
' /usr/share/dict/words
)
echo "$1" > /etc/myname
hostname "$1"
to rc.config
I found you should disable smtpd first though.
I had to change the pf.conf also to get this working or pf would randomly fail on line 9:
fw_net = “your fw ip”
set skip on lo
match in proto { udp tcp } from $fw_net to any port domain rdr-to 9.9.9.9 port domain
pass in proto { udp tcp } from $fw_net to any port domain
match out on egress inet from $fw_net to any nat-to (egress)
pass out on egress inet from $fw_net to any
block return # block stateless traffic
pass # establish keep-state
block return in on ! lo0 proto tcp to port 6000:6010
block return out log proto {tcp udp} user _pbuild
Hey. I’m trying to follow the guide (using install79.iso) but I find the steps aren’t exactly clear on a few things.
I’m following Setup guide 1
What am I supposed to set for em0? What IP address and netmask should I set for it?
I presume the gateway is the netvm I set for the standalone OpenBSD VM (i.e. sys-firewall)? I set sys-firewall’s IP address for em0?
Because that’s what I tried and then I was prompted with this.
Default IPv4 route? (IPv4 address or 'none')`
What am I supposed to do here?
And while we’re at it, is it possible to make my sys-net-openbsd disposable just like regular sys-net?
Until…
1 Like
It;s expected that you will at least understand a small amount about how
to configure a BSD system.
The handbook will help.
The IP for em0 will depend on the network that you connect to. If that
network expects that you will have a static address, then that
information will be provided to you. If the network provides DHCP then
you use inet autoconf in the configuration file.
Yes, the gateway is the netvm. Set this in /etc/mygate
In this configuration you have two routes.
Internet ← UpstreamNetwork ← NIC OpenBSD vif → sys-firewall → qubes
The default route will be via the upstream host on the network.
Try that.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Is it feasible to add “little something” to openBSD guest so it would be recognized as fully functional netvm?
(side thought: the fact that OpenBSD can work with mirage-firewall invalidates the hypothesis it is linux-bound and unfixable purely on Windows guest side, i need to return to this research)
I wonder how to access the local network with openbsd x mirage.
Solene’s script isn’t functional.
To my knowledge, the netback driver is lacking for OpenBSD to be used as a netvm 
Exactly so - this is why it’s necessary to run routes through
sys-firewall in the way we do.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Can you explain how your OpenBSD qube is set up, and exactly what you
are trying to do?
If you have a HVM and want to set mirage as the netvm, and be able to
access the network to which sys-net is attached, you dont need a script
for this. All you need do is normal networking:
configure xnf0 with the IP address
set /etc/mygate to the mirage IP
set /etc/resolv.conf to the usual Qubes DNS.
If you have a template based qube, you can do the same by storing the
local IP and mygate in /home, and pulling that information in using
/etc/rc.local
In my OpenBSD templates, I use /home/config to store this sort of data
nd then use it with:
if [[ -f /home/config/mygate ]]; then
cp /home/config/mygate /etc/mygate
fi
if [[ -f /home/config/myip ]]; then
QUBES_IP=`cat /home/config/myip `
ifconfig xnf0 $QUBES_IP up
sh /etc/netstart
fi
While I am able connect to the regular internet, I want to achieve something similar like: Solene'% : Script NAT on Qubes OS
Setup:
Standalone OpenBSD Qube
Mirage Firewall
Any server in the local network to be reached
The problem is that Solene’s script isn’t compatible with Mirage and one can not set OpenBSD as a netvm directly.
hm, there is xennet for netbsd. could it be ported to openbsd probably? upd: xnf(4) - OpenBSD manual pages isnt that enough? or do i miss something?
This is the netfront driver (i.e. the “client” side), and not the netback driver (i.e. the “netvm” side). For linux: linux/drivers/net/xen-netfront.c at master · torvalds/linux · GitHub vs linux/drivers/net/xen-netback/netback.c at master · torvalds/linux · GitHub
And for mirage we have now the same driver for both sides, with subtle protocol variants 
1 Like
ah! did not figure out that it is asymmetrical thing. is it that hard to port?
Well, it took me a lot of time just to factorise back end and frontend with both sides already written (but most of that time was to understand the protocol ).
So it’s certainly doable but not an easy thing
I still fail to understand your problem.
That script (if I recall) opens ports from sys-net down to a target
qube, making a qube accessible externally. I used a similar script
for many years, but have dropped it in favor of using qvm-connect-tcp.
But you say that you want to reach servers in the local network. What
exactly is your problem? Is there a special protocol running on those
server?
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I thought about it again and I think the issue is quite simple: MirageOS just does not allow to run commands from within. A possible work around is probably to replace the commands from Solene’s script with qvm-firewall.
Yes qubes-mirage-firewall has no shell but it works with qvm-firewall
Explain to me what your problem is. Why would you want/need to run commands
within Mirage-firewall to reach servers in the local network? There’s
something you are not saying.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Because the script does:
https://git.sr.ht/~solene/qubes-os-nat/tree/master/item/nat.sh @unman