Error opening Queue handle: protocol not supported

[githubjsorg]

I have successfully built and installed opensnitch using the guide but when the service tries to start it prints these 3 lines to /var/log/opensnitchd.log

[2018-09-29 16:35:15] IMP Starting opensnitch-daemon v1.0.0b [2018-09-29 16:35:15] INF Loading rules from /etc/opensnitchd/rules ... [2018-09-29 16:35:15] !!! Error while creating queue #0: Error opening Queue handle: protocol not supported

The service tries to start every 30 seconds and every time it prints those messages and fails.

I would be happy to provide any additional information that will help in finding and fixing this issue.

[Northern-Lights]

Do you have any other applications that are using netfilter?

[githubjsorg]

Not that I know of.

This is a fresh install of Debian Stable using debootstrap. The only things I installed before opensnitch and its dependencies were ssh, lxde, and nomachine.

[githubjsorg]

Is there a way for me to confirm this?

[githubjsorg]

Is there a solution to this issue? Or is there any other information I can provide?

[Northern-Lights]

The culprit is https://github.com/evilsocket/opensnitch/blob/master/daemon/netfilter/queue.go#L87 Unfortunately, I can't tell you why it would be returning with an error. This is before the queue is even created. It sounds like it would be something missing in your environment, but I don't know right now what that might be.

[githubjsorg]

Anything I can do to help you find the issue?

[Northern-Lights]

I'm not sure at the moment. I will have to try debootstrap sometime and see what's going on with it.

[githubjsorg]

If you want, I could debootstrap a Xen instance and give you SSH access to it.

[Northern-Lights]

Over a network probably isn't the best environment for working on a problematic firewall app. It looks simple enough to get installed anyhow, but thanks.

I am interested in how opensnitch would work with a debootstrap system, but I can't promise a quick turnaround or solution. Just after reading the description of debootstrap, I get the feeling that a lot of it is going to depend on what's installed on the host OS, so you might try installing dependencies and whatnot there, first. It's also unclear how the debootstrap system would intercept or even handle traffic which, I imagine, primarily comes through the original host OS.

[githubjsorg]

I made sure all dependencies were installed before building and installing opensnitch. The only other software installed was lxde and its dependencies, via apt. And I only installed that so I could test the GUI opensnitch client.

The debootstrap Xen guest would handle packets exactly the same as a native system. All packets have to go through the network stack of the kernel either way. The Xen guest is still running its own kernel, modules, drivers, etc.

As for testing the firewall over the network, I would say it isn't a big deal. Cause if you get locked out, that means the firewall is actually starting. My issue was not being able to get it started at all. Also, if you do get locked out, I can always login to its "local console" to get you back in.

[githubjsorg]

FYI, over Christmas I also tried with a fresh Debian Unstable deboostrap install. Same exact issue as Debian Stable.

[githubjsorg]

OK. Some additional information.

I installed Debian Stable using an install disk on a HVM (hardware virtual machine). After installing the latest golang (go1.11.4.linux-amd64.tar.gz), opensnitch install proceeded without a hitch AND opensnitch worked, but the UI performs very poorly (but that is a known issue).

More interestingly is that when I then boot that same install PV (ParaVirtualized), opensnitchd had the exact same issue as the debootstrap installs. So it sounds like it isn't an issue with the way it is installed but the hardware model it is run under. Somehow while run PV, it is missing some expected device?

Don't know if you have access to a Xen system but if you want, I can provide you the disk image and the PV and HVM configs I used for this latest test.

[githubjsorg]

Anything else I can do or provide to help with this?

[githubjsorg]

Is there any update on this bug?

[gustavo-iniguez-goya]

I have no idea what the problem might be, but just out of curiosity: can you post what kernel are you using, as well as the kernel modules loaded, and: grep -E "(NETFILTER|NETLINK)" /boot/config-$(uname -r)

nfq_open() calls nfnl_open(), so maybe the modules are not loaded, or the kernel is not compiled with netfilter/netlink support.

[githubjsorg]

Hi Gustavo,

I don't have that virtual machine any more. I will have to rebuild it and try the latest release of opensnitch. If/when I get a chance to do this. I will be happy to post this information.

[gustavo-iniguez-goya]

I've managed to compile (installing go1.13 manually...) and tested it on a Debian 8 (jessie), kernel 3.16.0. Note: By default the NFQUEUE kernel module is not loaded.

v@debian8:~/go/src/github.com/evilsocket/opensnitch/daemon$ uname -r
3.16.0-8-amd64

v@debian8:~/go/src/github.com/evilsocket/opensnitch/daemon$ sudo ./opensnitchd -debug -rules-path /etc/opensnitchd/rules -ui-socket "192.168.1.10:50051"
[2019-11-12 15:20:38]  IMP  Starting opensnitch-daemon v1.0.0b
[2019-11-12 15:20:38]  INF  Loading rules from /etc/opensnitchd/rules ...
[2019-11-12 15:20:38]  DBG  Starting 16 workers ...
[2019-11-12 15:20:38]  DBG  Rules watcher started on path /etc/opensnitchd/rules ...
[2019-11-12 15:20:38]  DBG  Stats worker #0 started.
(...)
[2019-11-12 15:20:38]  INF  Running on netfilter queue #0 ...
[2019-11-12 15:20:38]  DBG  UI service poller started for socket 192.168.1.10:50051
[2019-11-12 15:20:46]  INF  Connected to the UI service on 192.168.1.10:50051

^C
[2019-11-12 15:21:04]  IMP  Got signal: interrupt
[2019-11-12 15:21:04]  INF  Cleaning up ...
v@debian8:~/go/src/github.com/evilsocket/opensnitch/daemon$

As far as I can tell, the daemon works on this system compiled from latest sources.

[gustavo-iniguez-goya]

This problem is fixed with latest version. Regarding the loading of needed modules, I think that they're loaded once you add the NFQUEUE rule (if they were not already loaded.)