Hi:
I am trying install openwrt 18.06.1 at ubnt er-x device. the kernel version is 4.14. and I found that /porc/net/nf_conntrack is empy. and "conntrack -L" show nothing.
in old days if "nf_conntrack_ipv4" is loaded than there will be conntrack entry. I don't know what happened in kernel 4.14. do I need to look conntrack entries elsewhere or I miss something to enable the function?
Hi:
I found if I enable the firewall script, then there is /proc/net/nf_conntrack.
if I stop firewall script, then /proc/net/nf_conntrack is always empty.
so there is some magic behind the scene but I don't know what it is..
I tried to check the firewall script, and I found it call "fw3" to enable/disable the conntrack table.
I tried to compare "sysctl -a" before/after. but I still can not find what's the magic I need to learn.
Perhaps, I misunderstood; but this seems to be normal and expected behavior. If you disable the firewall, [connection tracking of] the firewall entries disappear.
the conntrack table is flushed when firewall disabled. but I don't understand why there is no new entries anymore. it's not the behavior of lede 17,openwrt 15 or earlier versions. so I am curious what's the magic.
and "conntrack" is a normal utility, it can delete single conntrack entry.
fw3 was created...and I do believe this occurred in 17. A developer that worked on it may be able to give more in-depth information (e.g. the commit that changed the behavior).
I never said it wasn't a normal utility, nor did I mention it's function, I only said:
that's the point and the magic I want to learn. conntrack table is a kernel internal feature. once you load the conntrack module, it should be working. I don't know how to turn it off. and most important, how to turn it on?
sorry for the misunderstanding. what I mention is "conntrack -L" return no entry. I didn't mean the command is missing.
bingo! now "ping -c 1 127.0.0.1 ; cat /proc/net/nf_conntrack" will bring you conntrack entries, although the added rule is not related to the traffic.
rules like "iptables -t nat -A PREROUTING -j DNAT" or "iptables -t nat -A POSTROUTING -J SNAT" will also bring back conntrack entries. but rules like "-j ACCEPT" will not bring anything.
At least for me, I'd argue that it's a feature that conntrack doesn't do anything by default if I'm not either implicitly enabling it with firewall rules that require connection tracking (some firewalls are purely static), or through some sysctl or other control. If I don't need it, why should it be chewing up CPU cycles and slowing down my machine? (Think dedicated web servers, for example)
in old days, if you don't need to track something, you can use NOTRACK target to bypass the tracking.
if it is a feature, it should have some sysctl parameters I think. and if you don't need tracking at all, you just don't load the conntrack kernel modules, which is the default for normal distributions like debian or rhel.
as you said, the conntrack is enabled by rules that required tracking. even if the rule is not related to the real traffic. it is strange to me.