Hi, after upgrading two machines from Debian Stretch to Debian Buster (shorewall 5.0.15.6 to 5.2.3.2), I noticed some dropped or rejected packet that I haven't seen before with the same rules. It seems to me that conntrack doesn't work the same as before. Some packets are treated as new while they aren't. Please note, it doesn't seem to make a difference whether I use the iptables-nft or iptables-legacy backend. I can see the messages in both cases.
A few examples from both machines: fw-dmz REJECT IN= OUT=enp3s0 SRC=2001:22b8:3498:9504:a9c3:4bd0:d4e9:6641 DST=2001:22b8:3498:9504:80ff:5dff:fe20:4937 LEN=60 TC=0 HOPLIMIT=64 FLOWLBL=602349 PROTO=UDP SPT=53 DPT=8077 LEN=20 The machine runs a DNS server and internal networks are allowed to access it. Once a day, the machine reconnects its PPPoE WAN connection and shorewall, shorewall6 as well as the DNS server are reloaded. Every time this happens, I get log messages such as this with the destination address of a particular client. It looks to me as if this packet is a reply to a legitimate packet from the dmz zone, but it is treated as a new connection from the firewall. Occasionally I can also see such rejected packets on port 53 with other destination addresses, but these are much less frequent and I can't make out a pattern in them. On a different machine which accepts connections to port 443 I also see replies being treated as new from time to time: fw-net ACCEPT IN= OUT=eth0 SRC=192.168.226.19 DST=82.179.95.16 LEN=138 TOS=0x00 PREC=0x00 TTL=64 ID=61910 DF PROTO=TCP SPT=443 DPT=8897 WINDOW=673 RES=0x00 ACK PSH FIN URGP=0 Please note: For debugging purposes I changed the default policy of fw-net to ACCEPT with logging enabled on this machine. Otherwise this packet would have been rejected while it is in fact a reply to a previous connection that I can see in my servers logs. One last example is with traffic passing through the firewall machine: lan-int REJECT IN=enp1s0 OUT=enp4s0 MAC=00:0d:***:08:00 SRC=192.168.131.30 DST=192.168.55.25 LEN=142 TOS=0x00 PREC=0x00 TTL=63 ID=59812 DF PROTO=TCP SPT=3483 DPT=49894 WINDOW=235 RES=0x00 ACK PSH FIN URGP=0 In this case the zone int is allowed to access port 3483 on zone lan. Here again the reply is being rejected, but this example here is actually the one that makes the most sense to me. I can only see these packets being rejected shortly after the firewall machine has been rebooted. Now it is logical that after a reboot the firewall doesn't know about previous connections anymore. But I'm wondering why I haven't seen such log messages before the upgrade to Debian Buster. There are a couple of areas that might have possibly changed: 1) shorewall's logging behavior: Maybe these packets were dropped all along but I never saw them in the logs? When I upgraded the machine I updated the configuration accordingly. I didn't change the log levels but I did update the default actions/macros like this: -DROP_DEFAULT=Drop -REJECT_DEFAULT=Reject +BLACKLIST_DEFAULT="Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL" +DROP_DEFAULT="Broadcast(DROP),Multicast(DROP)" +REJECT_DEFAULT="Broadcast(DROP),Multicast(DROP)" 2) nf_conntrack's defaults: I don't have a list of all the default sysctl conntrack values that were used on these machines on Debian Stretch. But I do set both net.netfilter.nf_conntrack_tcp_timeout_established and net.netfilter.nf_conntrack_udp_timeout manually and these values are the same as before. I browsed through the kernel logs to see if there were any changes in the default behaviour for connection tracking. I found one change that might be related, but it seems unlikely to me that it causes these packet drops: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.19.72&id=4d3a57f23dec59f0a2362e63540b2d01b37afe0a The reason why I think it's unlikely this particular change has something to do with it, is that on the second machine (with port 443 accessible) the interface never goes up and down except for the times the machine is shut down or (re)booted. But I see the rejected packets during operation. Also on the first machine, while the PPPoE device reconnects (i.e. it is removed and brought up again) regularly, none of the rejected packets actually involve the PPPoE interface. The other interfaces are static. But maybe netfilter's conntrack behavior is stricter with Linux 4.19 compared to 4.9 in other areas? 3) shorewall changing conntrack states during reload: I didn't find any evidence that points to shorewall resetting the conntrack table when it is reloaded, but maybe something else is changed (such as timeouts) when shorewall is reloaded? It wouldn't explain the rejected packet on the second machine, though, which occur at times when shorewall is simply running and not changed. So, this is the least likely option to me. Does anyone have any thoughts why this would happen? Thanks and regards, Timo _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
