Argh, iptables are killing me

[alexanderc]

Ok, maybe one of you has done more iptables than I have or know someone that has and can figure this one out

Comments

[sdaemon]

-A FORWARD --work-god-damn-it

[alexanderc]

Yes indeed. I'd do that if i could. :)

[sdaemon]

I wonder if changing back to the INPUT rule might not be your best bet...I forget the exact syntax, but wouldn't something along the lines of:

-A INPUT -s network.to.be.blocked/255.255.255.0 -dport porttobeblocked -j DROP

do what you're wanting?

I'm assuming that your internal webserver is running on a port other than 80, or that you have multiple live IPs. Otherwise, I don't see any way you can allow external addresses access to port 80 to one internal IP but not the other internal IP.

[alexanderc]

What I'm attempting is to block an external IP from some range from ever reaching my systems. From what I've been told, the input chain is only good for packets that are destined for my router. But there is no web server on the router, I'm forwarding port 80 onwards to a machine behind the router.

I've only got one live external IP and one port forward from external to internal.

[mike_b]

[sorry, weird keyboard spasm caused an early posting]

What're "prerouting_rule" and "postrouting_rule"? Knowing what those are might help with the issue.

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

If you're only testing with RELATED or ESTABLISHED flows, then yes, the DROP won't work because they are matching this rule first. You probably are testing with at least NEW flows, but I'm just pointing this out in case you haven't thought of that.

Remember you can always use -j LOG to see what's matching where.

Also, fwiw, I wasn't familiar with the TCPMSS target, and my manpage for iptables 1.3.6 says that target is only valid for the mangle table. Just sayin'.

That's all I have for now.

[alexanderc]

Sorry, I edited the rules slightly to make them more readable. prerouting_rule and postrouting_rule are subchains and technically the spots where I am supposed to make edits to the tables leaving the other tables as stock. Essentially every stock table, INPUT, OUTPUT, FORWARD, etc. has it's own lowercase "_rule" version where the user's rules are supposed to go. You can just ignore those lines in what I pasted above. There's nothing in those subchains that I haven't posted up there.

I don't see how the state related,established is matching because these are new packets coming into the system from the outside. Nothing is established yet (that I can tell). I suppose I can try to put the rule up there ahead of --state RELATED,ESTABLISHED and see what happens.

[mike_b]

I'd also be curious to know how br0 and vlan1 come into play with the router's physical interfaces.

[alexanderc]

I added my rule before the state rule and no go. It still lets that netblock through. As for the physical interfaces, let's see if I can find a summary