I have been trying for days to block one particular IP by using admin/scripts/firewall I am using a RT N16 with a USB 3G connection on 1.28.0000 MIPSR2-095 K26 USB Big-VPN I have tried these following versions that I have found, some on this forum and some from other sources iptables -t nat -A WANPREROUTING -s 67.210.248.14 -j LOGDROP # inbound iptables -t filter -A wanout -d 67.210.248.14 -j LOGDROP # outbound iptables -t nat -A WANPREROUTING -s 67.210.248.0/24 -j LOGDROP # inbound iptables -t filter -A wanout -d 67.210.248.0/24 -j LOGDROP # outbound and iptables -I FORWARD -d 67.210.248.14 -j LOGDROP I put these commands in admin/scripts/firewall - then Save - then Restart. My Log config is set to show blocked connections, its shows the above IP as connected (Accept.) QOS/view details show the IP connected and transferring data. I am puzzled by the fact that the Log shows no Blocked connections what so ever. I have spent days on this googling and reading. I am starting to think something is broken in the IP tables for this build. Thanks EDIT:- Solved - 1 flashed to 1.28.0000 MIPSR2-097 K26 USB Big-VPN - 2 used "iptables -I FORWARD -d 67.210.248.14 -j LOGDROP" in admin/scripts/firewall - restart. (same as previously tried ??) Works a treat, shows as blocked in log.
Your iptables rules look extremely odd, and they don't appear to be being done at the correct phase. Are you trying to block all traffic coming **from** 67.210.248.14 to your router, or are you trying to block **outgoing** traffic from your LAN **to** 67.210.248.14? The direction matters. If you're trying to block inbound connections, then there is no point in the "outbound" rules you put in place. Furthermore, you should be doing the blocking in the INPUT chain, not the FORWARD chain. By doing it in the FORWARD chain you're effectively wasting extra CPU time in the kernel for further processing that isn't needed. For clarification on what all the chain stages are (INPUT, OUTPUT, FORWARD, etc.), read Wikipedia: http://en.wikipedia.org/wiki/Iptables#Operational_summary So a correct example would be this: Code: iptables -I INPUT -s 67.210.248.14 -j LOGDROP You can verify the rule is working by doing iptables --list -n -v from the command line and looking at the pkts/bytes counter on that individual rule (they will increment whenever that rule is matched). Real-life example for testing: Before the rule is put in place -- ping is initiated from the machine (72.20.98.122) I'm going to block inbound connections from: Code: $ ping koitsu.strangled.net PING koitsu.strangled.net (67.180.84.87): 56 data bytes 64 bytes from 67.180.84.87: icmp_seq=0 ttl=53 time=16.229 ms 64 bytes from 67.180.84.87: icmp_seq=1 ttl=53 time=16.782 ms 64 bytes from 67.180.84.87: icmp_seq=2 ttl=53 time=16.093 ms ^C --- koitsu.strangled.net ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 16.093/16.368/16.782/0.298 ms Next, I add the rule on my router and verify it's there: Code: root@gw:/tmp/home/root# iptables -I INPUT -s 72.20.98.122 -j DROP root@gw:/tmp/home/root# iptables -L INPUT -v -n Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 72.20.98.122 0.0.0.0/0 ... Then trying the ping again: Code: $ ping koitsu.strangled.net PING koitsu.strangled.net (67.180.84.87): 56 data bytes ^C --- koitsu.strangled.net ping statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss Looking at the rule once more to examine counters: Code: root@gw:/tmp/home/root# iptables -L INPUT -v -n Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 4 336 DROP all -- * * 72.20.98.122 0.0.0.0/0 ... Note that I used -j DROP not -j LOGDROP because I do not have the logdrop module installed.
Hi and thank you for taking the time to provide such a detailed explanation. As you can see from the EDIT I got it to work after a fashion by reflashing the Router. However I will now use the info you have provided to do it "properly" Joe
