iptables - logging new connections

Solution 1:

Your rule consider packets that enter the router via eth0, are routed to be output from wlan0 and are new from the point of the connection tracker.

What is new? It is basically not what is expected or assured or replied and so on. When packet travels connection tracker, it is searched in its state table. The table contains source and destination addresses and ports, a state, timestamps when packets travelled either way, amount of data transmitted over this connection. If packet header data corresponds to some record in the table, that record is updated (for example, "expected" may be turned to "assured"), and a packet is assigned a connection tag. This packet won't travel any chain in the nat table; instead, if some transformations were recorded in the connection tracker table record, those are applied. And, of course, this packet will not be considered as starting new connection.

But, if nothing relevant is found in the table, a new record is created, packet is travelled through chains in the nat table and it is assigned a new connection tag.

By the way, -m state is an obsolete syntax. A modern is -m conntrack and its --ctstate parameter. (Now both seem to be handled by the same module, but historically these were different modules in the Netfilter.)

Now, think how packets are going through your router. A Netfilter packet flow diagram is very helpful here. So, let's assume someone behind wlan0 initiates a connection to internet. Then some packet appears from wlan0, it first recorded into the connection tracker, then router hopefully routes it to be output via eth0. Then it traverses a filter FORWARD chain, there it is checked against your "logging" rule (it doesn't apply, obviously). Then it traverses nat POSTROUTING, where it encounter a MASQUERADE rule. It is SNAT'ed by the rule, and a connection tracker record is updated with translation information, so follow-ups will be translated the same, and replies will be detected and translated back. Then it is output from eth0.

Any reply or follow-up packets will be assigned to this connection tracker record, and will not be tagged as new. They will be tagged as established, so they will not trigger your "logging" rule.

Also, if the connection is known to be, say, FTP control (tcp to port 21) and ftp connection tracker helper is enabled, it will scan all following packets of this connection for FTP data connection parameters (this is simplified explanation, but correct). If it sees them, the helper creates another connection tracker entry, with the data it captured from FTP control packet. The connection is created in related state; therefore, when FTP server connects back to the client to establish the data connection, first packet of that connection will not be tagged new, but related So it will not trigger your "logging" rule too.

Are there possible any packets that come in via eth0, must be output from wlan0 and will not be answers to the connections initiated from inside? Yes. Some system behind eth0 must have a route to the network which is behind wlan0 via the address assigned to the eth0 of your router. Then, if that system tries to use that route and send a packet to the address from wlan0 network (other than your router's address), such packet will trigger your "logging" rule.

Are there such systems in your setup? I don't know, but usually there aren't: you wouldn't install a NAT rule in the case there is route facing back your wlan0 network, the NAT wouldn't needed in that case to have replies back. So I think it's unlikely, however, possible.

Another possibility is DNAT case. Suppose you want to forward some port of your router to some machine inside, for example, forward tcp port 80 to the web server somewhere behind wlan0. Then you'll install a rule like this: iptables -A PREROUTING -d <eth0-address> -p tcp --dport 80 -j DNAT --to-destination <webserver-behind-wlan0-address>. The tcp packet destined to the eth0 address port 80 will be recorded into NAT table and tagged new, destination address changed to some address behind wlan0 and then routing will decide it must be sent out via wlan0. So it'll traverse filter FORWARD, where it will trigger your "logging" rule. Follow-up packets will be established, so they won't trigger that rule.

But you have no DNAT rules. So this scenario could not work.

A conclusion: I presume you have no systems behind eth0 which have routes to the network behind wlan0 via your router, and also you have no DNAT rules. There will be no packets in your network which could trigger this "logging" rule.

I already made this conclusion in my first comment to your question, here is just a verbose explanation how I concluded that.