Just to clarify and simplify the question my experience raises: There's a system functioning as a firewall with two public lines coming in, each with multiple IPs, and two LANs inside it. In this case the public lines are on eth4 and eth5, the two LANs are on eth1 and eth2. Rules for INPUT specify each of the ports which are to be open on eth4 and eth5, with a separate rule for each IP/port combination, and with a rule following them to reject all else on those interfaces. SMB ports are not among the the accepted traffic for those interfaces at all, not for a single public IP. But there's no blocking of SMB traffic on eth1 and eth2. There's an SMB service on the firewall by which workstations on the two LANs are able to place files for public-facing (non-SMB) servers there. All SMB probes seen as coming in on eth4 and eth5 get blocked, just as should be expected. But some SMB probes, of our public IPs, by outside public IPs, are seen by iptables as coming in on eth1 and eth2, so not blocked at that level. They can't connect successfully to our SMB server anyway because of its own settings. But that's not the point. The point is that some of the scans of our public IPs manage to appear to the firewall as coming from the internal interfaces - and I provided an example in the prior post where it is clearly a single, repeated scan that hits the internal interfaces with several, but not all, of its instances. Now, it's easy enough to block once it's recognized. It just takes adding rules to block the SMB ports on _all_ interfaces to anything with an external address, no matter which interface it appears to come in from. But this also suggests that the apparent interface of a packet, perhaps, just isn't to be trusted - that to be secure all rules must be 100% in terms of IP ranges, with interface specifications only to be considered a secondary, leaky line of defense. Admittedly this is an older netfilter, on an older kernel, since firewalls are the sort of thing where upgrade policies favor a conservative approach. Is there some known bug where packets can "slip sideways" between interfaces? What the heck can be going on here? Thanks, Whit -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
