As someone who abhors the introduction of MultiWAN support in Shibby tomato, esp. given all the other bugs that have yet to be addressed w/ the Routing Policy tab, I have to admit I've fallen behind wrt other changes in tomato. I'm stuck on on v132 for the foreseeable future. But in an effort to test some new policy based routing scripts w/ newer ARM-based routers (and not just my current fleet of older MIPS routers), I decided to test them against Shibby v138. What I found is that v138 is now blocking WAN->LAN access via the mangle table, and not the nat table, which afaik has been the tradition ever since the beginning of tomato (frankly, even that's wrong, it should be the FORWARD chain of the filter table, but we'll let that slide for the time being). Code: root@tomato-lab2:/tmp/home/root# iptables -t mangle -vnL PREROUTING Chain PREROUTING (policy ACCEPT 2636 packets, 485K bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- vlan2 * 0.0.0.0/0 192.168.1.0/24 0 0 DROP all -- vlan2 * 0.0.0.0/0 192.168.2.0/24 Why in the world was this change made? The implications are significant for anyone still implementing their own policy based routing because many of these scripts FLUSH the mangle table (in preparation for their own rules) in the belief there's nothing there of significance. And until this change in Shibby tomato, that was a valid assumption (at least if we assume QoS isn't enabled). Heck, I didn't even think DROP (or REJECT) was a valid target in the mangle table. As I said, I don't even like seeing this in the nat table since filtering should be done in the filter table. But this has pushed the filtering process as high as I've ever seen it in the routing process. And I'm trying to understand why it was done, esp. given it will break some scripts. It was always my understanding the mangle table was for altering packets (marking for policy routing, QoS, etc.). And if you weren't, you had no business being there. Now I understand ppl break rules all the time. And not always w/ the understanding of the implications. Which leads to my next concern. I can't get any my port forwards to work! Not until I flush the PREROUTING chain of the mangle table! LOL Code: iptables -t mangle -F PREROUTING Boom, instantly the ports forwards become active. Of course, I have no protection at all on the WAN now either. And yet, these same rules don't see to prevent reply packets from connections initiated inside the LAN and out to the internet from being handled properly. It's as if they are sensitive to state w/o having actually specified state on the rules themselves. All and all, I'm befuddled by what's going on here. I don't understand the reason for the change, nor the behavior I'm seeing in response to that change. Nor how it could be that no one else is reporting issues w/ port forwarding. For the record, I using an ASUS RT-AC68U w/ Shibby v138 (I know v138 has had issues, but I didn't see this one specifically).