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:
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…?
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?
Others (such as this one ) do not resolve to a website:
REJECT wan in: IN=pppoe-wan OUT= MAC= SRC=194.147.140.26 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?
