LXC Container is accessible from WAN after creation


I’ve created a LXC container on my Omnia using LuCI using the template “Ubuntu Focal” from “repo.turris.cz”. After the creation of the container I saw that inside of the syslog of Ubuntu there were logged many “REJECT” entries from external IP addresses:

REJECT wan in: IN=pppoe-wan OUT= MAC= SRC=<IP ADDRESS> DST=<IP ADDRESS> LEN=40 TOS=0x00 PREC=0x00 TTL=247 ID=59111 PROTO=TCP SPT=52525 DPT=11583 WINDOW=1024 RES=0x00 SYN URGP=0

As I didn’t have changed the firewall configuration of the router during the creation of the container I was surprised to see this entries inside of the log of the lxc container.
I looked at the firewall rules in LuCI and there was an entry “wan_http_turris_rule” (should be one of the defaults created by Foris I think) which was disabled. My next try was to activate this rule and afterwards the webinterface of Turris Omnia was accessible from the web. So I disabled the rule again and after this action the log inside of my LXC Container also stopped growing and there where no new REJECT entries.

I’m asking me if there is a common error when using LXC, so that the containers are accessible from web? As I didn’t modified the firewall rules before (always let Foris manage those) I’m surprised that the container was connected directly to the internet…?

1 Like

I’ve just checked the forum as I wanted to add a “Focal” LXC which lead me to this thread.

I also can report that I also see wan log entries on xenial too!

I have just ignored them so far but would be good to be reassured there is no security implication or an explanation why they are being seen


strange - have you tried to deactivate and reactivate the “wan_http_turris_rule”?
In my case after that action the entries in the log didn’t show up anymore…
Maybe @pepe can tell us more about this topic?

I don’t have a rule that looks like that on my TO but I do on the MOX (which is not WAN facing anyway). Is there a factory default rules list somewhere?

Here’s a snippet of my dmesg on a Debian LXC

REJECT wan in: IN=pppoe-wan OUT= MAC= SRC= DST=zz.zzz.zzz.zzz LEN=40 TOS=0x00 PREC=0x00 TTL=247 ID=30630 PROTO=TCP SPT=48397 DPT=9089 WINDOW=1200 RES=0x00 RST URGP=0

The above one resolves to http://openportstats.com/info

Others (such as this one ) do not resolve to a website:
REJECT wan in: IN=pppoe-wan OUT= MAC= SRC= DST=zz.zzz.zzz.zzz LEN=40 TOS=0x00 PREC=0x00 TTL=247 ID=14521 PROTO=TCP SPT=56001 DPT=43194 WINDOW=1200 RES=0x00 RST URGP=0

Interesting… because I haven’t created that rule "wan_http_turris_rule”… But I’m sure it was there all the time.

Generally the rule did nothing else than allow http access from wan to the Omnia - so maybe you could try to create this rule -> try if from your public IP the webinterface is accessible -> disable the rule afterwards. In my case after this action everything in the container was ok…

I could do but I also have WAN zone INPUT set to REJECT so shouldn’t need an additional rule to be added to resolve I would have thought?

I am not sure where the firewall rules diverged on my TO compared to the MOX, The TO was one of the original crowd funded ones, so could have some historical settings from way back then. The MOX came with TOS4 IIRC but I used the upgrade script on the TO to get to TOS4 (or 5, I really can’t recall!).

I do not recall altering any of the firewall traffic rules only the NAT rules, which is now empty of any rules.

Eh… you know containers share same kernel as host system so they read the same kernel messages. Firewall rule that is part of Sentinel Nikola causes these lines in kernel log. Notice that those are rejects because it was blocked by firewall.

I knew that, but thought that in the logs I would see only entries from the container itself… (my fault).
So why after the activation and disabling of the rule the lines were gone? I don’t think that this was a coincidence?

You are using Turris OS 3.x aren’t you? Turris firewall in there sometimes not manages rules correctly for uCollect. Meaning on firewall reload in some cases fw3 modifies reject and drop chains and that way it rejects and drops communication before Nikola logs it. For Turris 5.0 and Sentinel this was written from scratch and hopefully in a better way.

I’m sorry to inform you that I’m using Turris OS 5.1.5 (hbs), Kernelversion 4.14.206…
I’m not sure if Sentinel is always active, but I also do not have activated the Data Collection Package (only the Speed Measurment is active).

If I can help i could see whats in the log files if you guide me to the right point?

I’m running Turris OS version 5.1.5 HBS Kernel version 4.14.212
Also happy to provide logs if you let me know which ones :slight_smile: