1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Shibby v138 - WAN->LAN blocked in mangle table??

Discussion in 'Tomato Firmware' started by eibgrad, Mar 11, 2017.

  1. eibgrad

    eibgrad Network Guru Member

    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).
     
    Last edited: Mar 11, 2017
  2. Sean B.

    Sean B. Networkin' Nut Member

    I believe the reason reply packets from the internet to connections initiated from the LAN are not affected by the mangle rule is because the mangle table is traversed prior to the address being nat'd to local.. the destination IP would still be the WAN IP and not trigger on the LAN IP ranges of that mangle rule.. so the port forwards are likely getting jumped elsewhere down the line. Only way I'd see that happening. Not sure how much is different in shibbys iptables rules vs toastmans that I run.
     
    Last edited: Mar 11, 2017
  3. eibgrad

    eibgrad Network Guru Member

    Good observation, but then why don't my port forwards work until I flush the mangle table? Those should have the public IP as well. In fact, is we assume you're right, what's the point of these rules at all?
     
  4. Sean B.

    Sean B. Networkin' Nut Member

    I'd think something else down the line is jumping them back. My port forwarding works and I have the same rules set in mangle

    Code:
        0     0 DROP       all  --  vlan2  *       0.0.0.0/0            192.168.1.0/24                                   
        4  5888 DROP       all  --  vlan2  *       0.0.0.0/0            192.168.2.0/24
    As you can see, the counter shows hits on mine though. Not sure what it's catching.
     
  5. Sean B.

    Sean B. Networkin' Nut Member

    Perhaps the rules are set as lan to lan access restriction via WAN interface.
     
  6. eibgrad

    eibgrad Network Guru Member

    I can tally packet counts as well; if I attempt to ping the router's WAN ip, for example. Or access my port forwards. That's what lead me to flush the table and see if the port forwards now work. And they now do.
     
  7. eibgrad

    eibgrad Network Guru Member

    Hmm, but why those particular networks? Why not the entire private IP space (192.168.x.x, 10.x.x.x, 172.16.x.x). And even that doesn't make sense if that router is just daisy chained behind another local router.
     
  8. Sean B.

    Sean B. Networkin' Nut Member

    Sorry, I stated it wrong the first time. Re-wrote that post.
     
  9. Sean B.

    Sean B. Networkin' Nut Member

    I wrote it the first time having source/dest backwards. Wouldn't make sense having a destination for the LAN.. but would have applied if source was spoofed as LAN. I'm a bit confused on these rules now myself. What would be the reasoning behind a WAN packet having a LAN dest IP. And how are the counters getting hits.
     
  10. eibgrad

    eibgrad Network Guru Member

    These are all good ideas, but I don't think we've nailed it yet. You wouldn't be blocking cross local network access by referring to the WAN.

    Something else is going on here, and it's driving me crazy trying to find the rationale behind it.
     
  11. eibgrad

    eibgrad Network Guru Member

    I wonder is this is some attempt by Shibby to implement a kill switch over the WAN for when the OpenVPN client is active? Seems far fetched, but I'm currently grasping at straws.
     
  12. Sean B.

    Sean B. Networkin' Nut Member

    I think you may be on the right track. However I was under the impression VPN control/dns rules were only implemented if the VPN client or server was active.
     
  13. Sean B.

    Sean B. Networkin' Nut Member

    Perhaps these rules are related to the option for bypassing the VPN for internet traffic.
     
    IANS325 likes this.
  14. Sean B.

    Sean B. Networkin' Nut Member

    Unfortunately the code notes don't provide any reasoning either

    Code:
     685                                 // Drop incoming packets which destination IP address is to our LAN side directly
     686                                 ipt_write("-A PREROUTING -i %s -d %s/%s -j DROP\n",
     687                                         wanfaces.iface[i].name,
     688                                         lanaddr, lanmask);      // note: ipt will correct lanaddr
     689                                 if(strcmp(lan1addr,"")!=0)
     690                                         ipt_write("-A PREROUTING -i %s -d %s/%s -j DROP\n",
     691                                                 wanfaces.iface[i].name,
     692                                                 lan1addr, lan1mask);
     693                                 if(strcmp(lan2addr,"")!=0)
     694                                         ipt_write("-A PREROUTING -i %s -d %s/%s -j DROP\n",
     695                                                 wanfaces.iface[i].name,
     696                                                 lan2addr, lan2mask);
     697                                 if(strcmp(lan3addr,"")!=0)
     698                                         ipt_write("-A PREROUTING -i %s -d %s/%s -j DROP\n",
     699                                                 wanfaces.iface[i].name,
     700                                                 lan3addr, lan3mask);
    You probably already know this, but you could either pull the lines from the code and run a build or put iptables -t mangle -F PREROUTING in the firewall script as a work around.
     
  15. IANS325

    IANS325 New Member Member

    It would be great if we could have a web interface - where could put web domains that we wanted routed the ip to host rather that openvpn

    something like "all netflix traffic ip address" over rides opnvpn to those address ?
     

Share This Page