2

I have about 4 IP addresses that keep hitting a port on my network randomly I'd like to block. So I added the rules like this to my OpenWRT router:

iptables -I INPUT -s FIRST_PUBLIC_IP -p tcp --dport 32400 -j DROP
iptables -I INPUT -s SECOND_PUBLIC_IP -p tcp --dport 32400 -j DROP
iptables -I INPUT -s THIRD_PUBLIC_IP -p tcp --dport 32400 -j DROP
iptables -I INPUT -s FOURTH_PUBLIC_IP -p tcp --dport 32400 -j DROP

Then I also have this rule that writes to the log whenever there's a connection on that port

iptables -I FORWARD -p tcp --dport 32400 -m limit --limit 1/min -j LOG --log-prefix "PLEX Connection "

So what I thought would be happening is if 1 of the 4 IP addresses listed tried to connect on that port, they'd just get dropped and never make it to the forward chain. Everything else would trigger that logging rule.

However, those IP addresses are still logged via the FORWARD rule. They are live now and made them permanent on reboot. What have I overlooked?

6

Packets that surf the FORWARD table don't hit the INPUT table. So, if your packets are actually hitting the FORWARD table, they're probably being natted or something similar -- which is okay, but it means you can't use INPUT rules to affect them.

There's a great reference diagram - daunting to read but great for reference - at the Netfilter entry in Wikipedia: https://en.wikipedia.org/wiki/Netfilter#/media/File:Netfilter-packet-flow.svg .

But I suspect you are doing some mangling of packets, and that's why it's not immediately obvious. Consider adding your rules - as kludgey as it is - into the PreRouting in nat, or into the FORWARD table instead, and see the behaviour change.

Good luck, and please expand on your question if you need.

1
  • Thank you for the explanation. I don't know why I thought it hit INPUT and FORWARD, but I did. It makes more sense now. I'll probably just put my rules in the FORWARD table for simplicity sake (and because I'm still tinkering and done quite get the prerouting and all that yet).
    – Nathan
    Nov 6 '16 at 1:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.