Hello, I am attempting to use conntrackd in FT-FW mode using my Chromebook (crostini, Ubuntu 18.04 container). I’ve tried both using Multicast and UDP. In both cases, I receive the error shown at the bottom of this message. It would appear that conntrackd is performing a privileged operation that requires the container to operate in privileged mode. Unfortunately, it also seems as though Crostini won’t allow privileged containers to run. I am going to attempt nested containers to see if I can bypass this restriction. But, I thought it might be a good idea to post a general question to see if I’m missing something or if anyone might have an alternative suggestion.
Thanks in advance!
[Sat Mar 2 00:49:57 2019] (pid=632) [ERROR] conntrackd cannot start, please review your configuration
[Sat Mar 2 00:49:58 2019] (pid=633) [warning] Cannot set nice level -20: Operation not permitted
[Sat Mar 2 00:49:58 2019] (pid=633) [ERROR] can’t open channel socket: Operation not permitted
[Sat Mar 2 00:49:58 2019] (pid=633) [ERROR] initialization failed
[Sat Mar 2 00:49:58 2019] (pid=633) [ERROR] conntrackd cannot start, please review your configuratio
I suspect this is either a missing kernel module/feature or just that the kernel doesn’t allow root inside an unprivileged container to do that.
Given how well network stuff is usually namespaced, missing kernel support or missing kernel module seems more likely. If you know what module you need and it’s present in the VM (termina) then you could set it as linux.kernel_modules so LXD loads the module on startup.
I tried loading the modules (nf_conntrack, nf_conntrack_ftp) both in the container configuration and the default profile, but the problem seems to persist. Additionally, I am still not able to to execute a lsmod within the container to verify the module is loaded. When I attempt the lsmod command, I receive the error at the end of this message.
LXD within the Termina VM does not give me an error when I set the linux.kernel_modules configuration item, so I can only assume the container sees the module as properly loaded.
Thanks for the help! It is very much appreciated!
root@lab1-fw1:~# lsmod
libkmod: ERROR …/libkmod/libkmod-module.c:1657 kmod_module_new_from_loaded: could not open /proc/modules: No such file or directory
Error: could not get list of modules: No such file or directory
root@lab1-fw1:~#
Hmm, lack of /proc/modules means that the kernel used on the Chromebook doesn’t use modules at all, that’s going to be a problem.
You may still be able to look at /sys/modules for what’s available in the kernel, but lack of module loading capabilities will mean that what’s supported out of the box is the extent of what you’ll get.
You may want to file a bug against chromiumos and have them enable what’s needed in the kernel:
I had the same problem. Running “strace” on the “conntrackd” command revealed that the problem is with a setsockopt() system call which uses SO_SNDBUFFORCE to force a larger buffer size i.a.w. the conntrackd.conf option “SndSocketBuffer”.
Since SO_SNDBUFFORCE is only allowed for privileged (CAP_NET_ADMIN) processes, and my LXD container is unprivileged (the container root user does not have id=0 on the host and therefore is not privileged) the call fails.
As a test I tried making the container privileged (and unsecure) using the command “lxc config set security.privileged true”. After rebooting the container conntrackd would now start without any problems. So this confirmed that this is a matter of privileges.
Looking into the conntrackd source code I could see that SO_SNDBUFFORCE is only used when specifying the conntrackd.conf option “SndSocketBuffer”. When this is not the case default buffer sizes will be used instead - which doesn’t require special privileges.
Removing “SndSocketBuffer” and “RcvSocketBuffer” options from my conntrackd.conf file confirmed this: Now conntrackd runs fine within an unprivileged container.
Be aware though that according to the conntrackd.conf manual page not specifying “SndSocketBuffer” and “RcvSocketBuffer” can result in packet loss and thus loosing conntrack state information on a busy firewall. This might be mitigated by using TCP instead of MCAST or UDP. Similarly using conntrackd mode FTFW instead of mode NOTRACK probably mitigates the issue as well since FTFW (according to the man page) is based on a reliable protocol which can recover from message loss.
Another option could be to increase the buffer sizes on the LXD host which will then affect all containers. This could be done using sysctl to configure the buffer sizes recommended in the conntrackd.conf manual page:
sysctl -w net.core.rmem_default=1249280
sysctl -w net.core.rmem_max=1249280
sysctl -w net.core.wmem_default=1249280
sysctl -w net.core.wmem_max=1249280
Of course souch a change might cause other problems on a busy LXD host so I will probably use mode FTFW instead to solve the problem without having to change the buffer sizes.
I had temporarily put this issue “on the shelf” and decided to simply use a single firewall, versus a firewall pair connected via conntrackd, to test my internal network container test lab.
Now, thanks to your help, I’ll revisit this issue SOON!
I’m just sorry I hadn’t noticed your message until just now!