On Tue, Jul 12, 2022 at 7:35 AM Laurence Perkins <lperk...@openeye.net> wrote:
> Ok, I asked a while ago about whitelisting MAC ranges for firewall rules, > and just so you know, adding 16 million potential MAC addresses to the > firewall… Doesn’t work well… No matter how you do it. So I had to write > a daemon to monitor which ones were local and add just those. Whatever. > > > > That brings me to the next problem. The routing and NAT work just fine if > I’m letting everything through. But if I’m dropping connections that don’t > come from authorized devices then UDP only works in the outbound > direction… TCP is fine. > > > > For reference, the rules consist of: > > > > iptables -t nat -I POSTROUTING -o <OUTSIDE> -j MASQUERADE > > iptables -A FORWARD -i <OUTSIDE> -o <INSIDE> -m state --state > RELATED,ESTABLISHED -j ACCEPT > > > > And then the daemon adds a: > > iptables -A FORWARD -i <INSIDE> -o <OUTSIDE> -m mac --mac-source <MAC > ADDRESS> -j ACCEPT > > > > for each authorized device. > > > > TCP works perfectly. > > UDP based protocols send out just fine, but any replies get blocked if the > FORWARD chain’s default policy is DROP. > > > > Now… Everything I’m reading says that it’s supposed to be able to > associate UDP replies based on port number, which indeed it must be doing > in order for them to get translated correctly and directed to the correct > device inside the NAT when the default policy is ACCEPT. > > > > So why is that rule to accept related packets not triggering for them? > I also would have expected the UDP replies to be permitted via -state RELATED,ESTABLISHED. Do they at least get into the state table; grep udp /proc/net/nf_conntrack
