stock, updated Qubes 4.0 with KDE installed according to the forum here (It’s great).
I set up a a ProxyVM as a VPN gateway using iptables and CLI scripts following the instructions here exactly, using the Debian 10 template. I tried twice to reduce the possibility of human error.
It seems to work fine, AppVMs connected to it seem go through the VPN when tested by ipleak and a visual network monitor.
The VPN Gateway won’t shut down however, and must be killed after choosing the “wait” prompt several times.
The log for the VPN Gateway at /var/log/xen/console has many lines with “A stop job is running for Qubes misc post-boot actions” at the end.
Searching for variations of this error message got nothing.
Any hints or pointers from someone who’s got a moment?
A secondary issue that arose is that either the VPN Gateway VM or the AppVM connected to it appear to be making connections to IP adresses other than the VPN servers, according to a visual network monitor AppVM the VPN Gateway VM is connected to.
The second topic is basically the common question on the forum: How to definitively configure a firewall setup so that only connections that the user wants are made?
Having searched everything on the forum that may be related over the last couple of months I’m still not clear, and far from confident that some firewall won’t fall open or something. Even power users appear to be having trouble with this.
Back to the main topic:
Does anyone have any pointers on how to troubleshoot the log error message "A stop job is running for Qubes misc post-boot actions” - there seems to be nothing online.
The VPN Gateway VM seems to be operating fine apart from throwing that error message and needing to be killed to shutdown.
post-boot-actions means that you should probably look at the way systemd stops services when the computer shuts down. Most likely some service is broken that depends on “qubes misc post-boot-actions.target” or something like this and the broken service doesn’t react to SIGKILL. Thus the shutdown process can’t reach the shutdown target, can’t continue the shutdown and thus won’t finish shutting down until you kill the VM. (though that’s just my speculation from the error message, could be that I’m totally wrong about this )