Iptables TRACE target and LXD containers not doing anything?

LXD
1

I am writing an Ansible role and testing it with molecule on LXD containers running on Travis CI (on a google compute instance, not in a docker container)

My role sets some very basic iptables rules:

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp --dport ssh -j ACCEPT

When I test this role with molecule, it creates an unprivileged containers running Ubuntu 18.04 and applies the role to it to simulate applying the role to an actual host. Then testinfra runs and inspects the state of the system within the container to compare it to test cases I wrote. I have remapped the uid and gid both on my local system and on Travis for the lxd and root users to 1000000000.

The issue is that testing this way works perfectly locally, but if I get the exact same test to run on Travis then it can’t access any destination on the internet anymore from within the container (network unreachable). This only happens after applying the firewall rules above, it works fine before.

I’d like to debug what’s going on, and the easiest way is to use the TRACE or at least the LOG targets in iptables. But it looks like these aren’t available in the container: the packet count goes up for LOG and TRACE rules, but it doesn’t seem to output anything anywhere (/var/log/kern.log doesn’t even exist in the container, and there is no output relating to these rules on the host.)

How do I get iptables from within the containers to output data from the TRACE and LOG targets?

2

Your firewall drops all INPUT traffic, which will include replies to packets you’re sending out, you need something like this at least:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
3

That makes a lot of sense, I hadn’t thought about it!

Is there any reason why I couldn’t get any output from the TRACE rules? If I look in /var/log/syslog, I see error messages from rsyslog that /proc/kmsg can’t be opened; any way to get kernel logging to work within the container?

4

dmesg should work to access the kernel log buffer, unless the proc setting disallowing access to unprivileged users was set on the host.

5

Bu then it would show the host’s kernel log buffer when calling dmesg from within the container, wouldn’t it?

6

There is no per-conainer kernel buffers, so either those netfilter events are hitting the main kernel log, in which case they’d show up in dmesg or they’re being dropped entirely.