从你的描述来看，核心问题是不对称路由触发的防火墙状态检测拦截，结合你提到启用GW2的NAT后恢复正常，这个判断应该是准确的。下面拆解原因并给出具体解决方案：

问题分析 #

目前的路由路径存在不对称性：

• QNAP ping Windows：QNAP → GW2 → Windows（符合QNAP配置的静态路由规则）
• Windows ping QNAP：Windows → GW1 → QNAP（Windows默认网关指向GW1，且未配置到172.16.4.0/22的特殊路由）

这种路径不匹配会触发网关的状态检测机制：GW2在转发QNAP到Windows的回包时，找不到对应的请求会话（因为请求包是通过GW1发送的，从未经过GW2），所以会直接丢弃回包；同理，如果GW1开启了状态检测，也可能出现类似拦截。而启用GW2的NAT后，所有来自172.16.16.0/22的包都会被转换成GW2的172.16.4.2地址，此时路径变成完全对称的（Windows→GW2→QNAP，QNAP→GW2→Windows），会话匹配，所以能正常通信。

另外也需要排除QNAP防火墙的入站限制：可能QNAP默认只允许来自本地网段（172.16.4.0/22）的ICMP请求，拒绝来自172.16.16.0/22的请求，启用NAT后源地址变成GW2的172.16.4.2（属于本地网段），所以能通过。

解决方案 #

方案1：配置对称路由（推荐） #

让Windows发往QNAP的包也走GW2，确保请求和回包路径一致：
在Windows设备上添加一条到172.16.4.0/22网段的静态路由，命令如下：

route add 172.16.4.0 mask 255.255.252.0 172.16.4.2 -p

参数-p表示这条路由永久生效，重启后不会丢失。

配置完成后，Windows ping QNAP的路径变为：Windows→GW2→QNAP，回包路径是QNAP→GW2→Windows，完全对称，状态检测防火墙不会再拦截。

方案2：调整GW2的防火墙规则 #

如果无法修改Windows路由，可以关闭GW2的状态检测功能，或者添加规则允许不对称路由的ICMP包通过。具体操作参考GW2的防火墙配置界面，找到“状态检测”或“会话匹配”相关选项，暂时关闭测试，或者针对172.16.4.0/22和172.16.16.0/22的ICMP流量添加允许规则。

方案3：检查QNAP的防火墙入站规则 #

登录QNAP管理界面，查看防火墙入站规则，确认是否允许来自172.16.16.0/22网段的ICMP回显请求（Ping）。如果没有相关规则，添加一条允许规则：

• 来源：172.16.16.0/22
• 协议：ICMP
• 动作：允许

验证步骤 #

1. 在Windows上执行tracert 172.16.4.10，确认第一跳是GW2（172.16.4.2）而非GW1。
2. 再次尝试ping QNAP，查看是否能正常通信。
3. 如果仍不通，可以在GW2上抓包，确认是否收到Windows的ping请求和QNAP的回包，进一步定位问题。

内容的提问来源于stack exchange，提问作者leon