Why does Cloudflare's 1.1.1.1 allow you to bypass MAC filltering?

Solution 1:

A lot of home gateways run Linux and use the 'iptables' firewall. Most likely the MAC-based filtering is implemented as the same kind of 'iptables' firewall rules as normal TCP/UDP filtering – and what they both have in common is that in most typical setups, they're only applied to the initial packet of each connection.

Most firewalls are stateful and remember all individual packet "flows" they see (be it TCP connections or UDP streams), meaning they will only check the initial packet of a flow against rules, but all further packets will be immediately accepted. Among other things, this is necessary to make NAT work (the router has to remember how to un-NAT packets going in the other direction), but it is also used by regular firewall rules – very often, the first rule in iptables rulesets is "accept if packet belongs to an established connection".

For example, if your firewall allowed e.g. inbound SSH connections on port 22, then you deleted that rule (or indeed even if you added a deny rule for port 22) while one such inbound SSH connection was still active, the high-priority "allow established" rule would still keep allowing that connection until it was closed. Similarly, an outbound VPN tunnel is seen as a single continuous flow; as long as you stay connected to the VPN server, even if the VPN port is blocked later, the stateful firewall may continue allowing that connection through.

So I strongly suspect that your MAC-based filtering is implemented in exactly the same way, with the rules having the same priorities. That is, I suspect that your router still starts with an "allow established" rule that accepts every already active connection no matter where it's from, and only then you have "allow from <list of MACs>" rules that implement the filtering.

_{(Now there's nothing in iptables that would mandate the "allow established" to be the very first – it is certainly possible to add "immediate deny" rules before it – but the point here isn't about what can be done in theory, it's about how it was most likely done in your router in practice.}

_{Similarly, it is certainly possible to "kick" connections out of iptables' flow cache and force them to be re-evaluated against the rules, but this is usually not done because it's difficult to guess in an automated way which flows should be removed – and just clearing it all out would cause unnecessary interruptions to everyone's connections through the router, especially because the same cache also keeps track of NAT mappings for each connection.)}