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

Shibby 097 buildTomatoUSB WAN link ICMP Issue

Discussion in 'Tomato Firmware' started by rokr1, Jul 27, 2012.

  1. rokr1

    rokr1 Networkin' Nut Member

    Hi Shibby,

    Seems like iptables is not configured properly. "Respond to ICMP" in firewall is unchecked and still I am able to ping the WAN IP address. IP table shows INPUT to drop but first line again contradict the default policy and accepts all connection. Limiting ICMP works. Need Assistance :)
     
  2. shibby20

    shibby20 Network Guru Member

    version? On my RT-N66U + 097 all works fine. When i disable "Respond to ICMP" i`m not albe to ping my WAN ip address fron outside.

    IPTABLES when ICMP is enabled:
    and disable:
     
  3. rokr1

    rokr1 Networkin' Nut Member

    I am using 097 Build and ASUS RT-N16 with AIO firmware.

    Here is my Iptables dump. Almost nothing changes.

    ICMP Enabled

    Chain INPUT (policy DROP)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    ACCEPT udp -- anywhere anywhere udp dpt:4505
    DROP all -- anywhere anywhere state INVALID
    ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
    shlimit tcp -- anywhere anywhere tcp dpt:ssh state NEW
    shlimit tcp -- anywhere anywhere tcp dpt:4502 state NEW
    shlimit tcp -- anywhere anywhere tcp dpt:4503 state NEW
    ACCEPT all -- anywhere anywhere
    ACCEPT all -- anywhere anywhere
    logaccept icmp -- anywhere anywhere
    logaccept udp -- anywhere anywhere udp dpts:33434:33534
    logaccept tcp -- anywhere anywhere tcp dpt:4501
    logaccept tcp -- anywhere anywhere tcp dpt:4502
    ACCEPT igmp -- anywhere base-address.mcast.net/4
    ACCEPT udp -- anywhere base-address.mcast.net/4 udp dpt:!upnp
    logdrop all -- anywhere anywhere

    ICMP Disabled

    Chain INPUT (policy DROP)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    ACCEPT udp -- anywhere anywhere udp dpt:4505
    DROP all -- anywhere anywhere state INVALID
    ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
    shlimit tcp -- anywhere anywhere tcp dpt:ssh state NEW
    shlimit tcp -- anywhere anywhere tcp dpt:4502 state NEW
    shlimit tcp -- anywhere anywhere tcp dpt:4503 state NEW
    ACCEPT all -- anywhere anywhere
    ACCEPT all -- anywhere anywhere
    logaccept tcp -- anywhere anywhere tcp dpt:4501
    logaccept tcp -- anywhere anywhere tcp dpt:4502
    ACCEPT igmp -- anywhere base-address.mcast.net/4
    ACCEPT udp -- anywhere base-address.mcast.net/4 udp dpt:!upnp
    logdrop all -- anywhere anywhere
     
  4. rokr1

    rokr1 Networkin' Nut Member

    Seems like nvram changes block_wan=0 to 1, how ever it does not change the iptables
     
  5. shibby20

    shibby20 Network Guru Member

    propably you have something wrong in nvram. I suppose you have to try erase all nvram datas.

    why you have ACCEPT all -- anywhere anywhere
    you should have ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
    as i have
     
  6. rokr1

    rokr1 Networkin' Nut Member

    It should happen automatically. I did clear the NVram, however I will try the same and let you know.
     
  7. koitsu

    koitsu Network Guru Member

    You shouldn't just "clear the NVRAM", you should do a "thorough erase of NVRAM" -- there's a difference.

    After doing this, you need to manually change all the settings. Rephrased: DO NOT restore from a configuration file or else you'll just be putting back the same NVRAM variables that could be causing this problem. I've explained this in another thread (read it slowly and in full, DO NOT SKIM):

    http://www.linksysinfo.org/index.php?threads/tomato-1-28-to-toastman-mod.38310/

    The way I deal with this is that I keep a text file which has all of my settings in it, and every time I upgrade/change firmwares I do a thorough NVRAM reset then manually go through and choose all the settings using the text file as reminder of what's what. That's just the way it works.

    Furthermore, if you have any scripts/etc. in Admin -> Scripts (in any of the sections, not just Firewall!), you should post them. It may be that you have something that's messing about with your firewall rules.
     
  8. rokr1

    rokr1 Networkin' Nut Member

    Yes I did clear and erased the nvram as well as manually configured
     
  9. rokr1

    rokr1 Networkin' Nut Member

    still the same. I cleared and erased and did all, no matter what I do I can ping WAN IP from other link, switching back to Original Tomato USB (Seems stable for me)
     
  10. rokr1

    rokr1 Networkin' Nut Member

    After generic Tomatousb firmware upgrade I am not experiencing the issue, here is a snapshot of my iptables,

    Chain INPUT (policy DROP)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    ACCEPT udp -- anywhere anywhere udp dpt:4505
    DROP all -- anywhere MY WAN IP ==> This one is missing in your mod
    logdrop all -- anywhere anywhere state INVALID
    ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
    shlimit tcp -- anywhere anywhere tcp dpt:ssh state NEW
    shlimit tcp -- anywhere anywhere tcp dpt:4503 state NEW
    ACCEPT all -- anywhere anywhere
    ACCEPT all -- anywhere anywhere
    logaccept tcp -- anywhere gateway tcp dpt:https
    logaccept tcp -- anywhere gateway tcp dpt:ssh
    logdrop all -- anywhere anywhere

    To replicate the issue try enabling VPN (OpenVPN and PPTP) also enable multicast. Drop wan link $(nvram show|grep wan_ipaddr=|cut -d'=' -f2) or $(nvram get wan_ipaddr) as destination in iptables is a workaround. But please correct this.
     

Share This Page