如果开启了硬件 IP 包转发，那么路由器的 iptables 规则是不生效的。

[tool2d]

也不是完全不生效，有 90%流量不走 iptables DROP 规则，直接硬件 HNAT 转发出去了，完全拦截不下来。

昨天百思不得其解，tcpdump 也拦截不下来，明明就是有数据通过的。今天发现只要把硬件 IP 包转发关闭，也就是（ Hardware NAT 功能关闭），就恢复正常了。

路由器毕竟不是传统的 LINUX ，吃了经验的亏。

[tool2d]

昨天我试了

iptables -t raw -I PREROUTING 1 -m mac --mac-source fc:aa:14:43:12:23 -j DROP

对 TCP 和 ICMP 立刻生效，对一部分 UDP 不生效。

真是整的怀疑人生，能不能拦截包，全看路由器的心情。

[emeab]

Hardware NAT 优先级比 iptables 优先级高

[ranaanna]

为什么一定要在 raw 表中定义 drop ？是出于 drop early drop fast ，从而减少系统开销的考虑？较早的时候 raw 表唯一的功能是给数据包一个 notrack ，所以也许是你的路由器在设计的时候并没有预料到你会这么早 drop 掉数据包？
何不在缺省的 filter 表中试试，给系统预设的硬件加速一个机会？

[tool2d]

@ranaanna 正常来说，也不是一开始对 raw 表下手的。是-t filter FORWARD 没生效后，就死马当活马医。

当时我并不知道硬件加速会跳过一些 UDP 包，用 iptables -vL 看 pkts 数量完全不涨，但又不是 100%复现，所以才迷茫。

[ranaanna]

@tool2d 用 INPUT 链试试看？另外，对于 UDP ，是不是要用 REJECT ？不然对方没有出错信息，只是以为“拦截不下来”

[tool2d]

@ranaanna 刚试了一下 INPUT ，不行。路由器只是转发包，走 FORWARD ，最终接收才是走 INPUT 。

看 https://zersh01.github.io/iptables_interactive_scheme/ ，INPUT 和 FORWARD 似乎是两条分叉路径，二选一。

[ogodeikhan24k]

1. 你路由器是哪家平台？比如高通家的一般是 session 首包是走协议栈，后面包是走 fast path 的
2. 你如果过滤 mac ，可以尝试下 ebtables ， 不用 iptables

[tool2d]

@ogodeikhan24k MTK Arm 的，我看 HNAT 表现和你说的高通很类似，只要 conntrack 没有代表首包，全部拦截下来了。后面 UDP 就是走 fast path 。