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
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:
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
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
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.
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)
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.