New to networking and this is my first time working with iptables. I only want one subnet to access my file server. Anyone have experience doing this? Going to apply this rule on my router that has dd-wrt installed.

with iptables on the router; this assumes you have a default DROP setting on the FORWARD chain, fileserver address 192.168.3.3, and the subnet you wish to allow 192.168.2.0/24:

you could also, if you don't want to default DROP everything in the FORWARD chain, block access by undesired subnet:

a bit more info on your network topology might be helpful

Thanks for the reply. We are in medical research and because of the windows xp eol we are required to upgrade to windows 7. But we have computers that we can not upgrade because we have devices (microscopes) connected to these computers and there software only runs on windows xp. To upgrade the computer we would have to spend over $10,000 to replace everything. We got the OK from the IT department to use a router to block access to the internet and only have access to servers on our network. From doing research this is the firewall rules that I used to allow access to services that we use. It seems to work, it blocks access to the internet and can access servers. I just want computers on our subnet (123.456.x.x) to access our servers (123.456.42.x). Here is the rules I used, I know its not the cleanest.

iptables -I FORWARD 1 -p tcp -m multiport --dports 25,53,67,88,123,389,636,2535,3268,3269,5722,8014,8040,8041,9389 -j ACCEPT
iptables -I FORWARD 2 -p udp -m multiport --dports 25,53,67,88,123,389,636,2535,3268,3269,5722,8014,8040,8041,9389 -j ACCEPT
iptables -I FORWARD 3 -p tcp --dport 135:142 -j ACCEPT
iptables -I FORWARD 4 -p udp --dport 135:142 -j ACCEPT
iptables -I FORWARD 5 -p tcp --dport 443:462 -j ACCEPT
iptables -I FORWARD 6 -p udp --dport 443:462 -j ACCEPT
iptables -I FORWARD 7 -p tcp --dport 4280:4286 -j ACCEPT
iptables -I FORWARD 8 -p udp --dport 4280:4286 -j ACCEPT
iptables -I FORWARD 9 -p tcp --dport 9100:9102 -j ACCEPT
iptables -I FORWARD 10 -p udp --dport 9100:9102 -j ACCEPT
iptables -I FORWARD 11 -p tcp --dport 49152:65535 -j ACCEPT
iptables -I FORWARD 11 -p udp --dport 49152:65535 -j ACCEPT
iptables -I FORWARD 12 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 13 -j DROP

in a general sense, i would add this, in between rule 11 and 12:

more importantly, is your default action for the FORWARD chain set to DROP? as well, posting your entire rules might help (iptables -nvxL)

Thanks for your help. Yes I posted the entire rules I used in my last reply. When you say my default action for forward chain set to DROP, this should by my first rule?

iptables -I FORWARD DROP

And then the rules I posted come after?

I'm sorry for barging into this late but...

Well, no, that's not important. The last rule in that chain is 'drop', so all packets will be dropped before they ever get there and even if they did get there, which they won't, they would only get the same action as the 'drop' rule.

OK, a bit of detail: for inbuilt chains (only!), there is a chain policy. This policy defines what happens if packets get to the end of the chain without matching any of the other rules, and getting sent off elsewhere.

There is nothing inferior about doing the same thing with an explicit rule. It is just the same thing done differently (although you will see a lot of advice on t'internet that claims that the only safe thing to do is use a 'drop' policy - this is information from people who haven't understood how iptables actually works, and are just repeating partly understood information). There is one case where the explicit rule approach has an advantage, but it doesn't really apply here, provided that the router is local.

i) in code tags please...much more readable
ii) it is a firewall, you are knocking a lot of holes in the firewall and the more holes that you have, the less like a firewall and the more like not-a-firewall it is
iii) this is not the most efficient way of achieving this objective (part i); with that 'established, related' rule further up (eg, at the top), there would be fewer comparisons to be done and so it would use less cpu time on the router; this may not be important, depending on the level of traffic
iv) this is not the most efficient way of achieving this objective (part ii); you could use ipset to do fancy 'multi-matches' more efficiently, there would be fewer comparisons to be done and so it would use less cpu time on the router; this may not be important, depending on the level of traffic
v) this is not the most efficient way of achieving this objective (part iii); because you do the same thing for tcp and udp, you could peel the udp and tcp traffic into a separate chain, you could then do roughly half the number of comparisons to get the same result, there would be fewer comparisons to be done and so it would use less cpu time on the router; this may not be important, depending on the level of traffic
vi) that dport 49152:65535; that rule is letting through nearly half of all ports!; I'd bet you don't really need to let through all of that

here is one simple re-write (and I haven't checked the syntax, so no guarantees); you would need to define a chain called tcpudp and forget the syntax for that; treat this as 'pseudocode'

(you have specifically allowed the 'bootp' protocol through; are some of these boxes 'thin clients'?)

Anyway, I hope that you can do it that way (untested, etc, etc). Another approach, rather than filtering off the protocols that you want to process into a separate chain would be to explicitly filter out the protocols that you don't want at the top, so that just tcp and udp make their way down the chain. I still think that the 49152:65535 range looks unnecessarily permissive, though...

@gtribe
No, that will break everything.

fair enough. my mistake.

and while the rest of your post contains fantastically good information... does it really help the original poster further towards the original task, of only allowing 1 subnet access to another one?

i provided a caveman-like simple example, of using "-s" (source) and "-d" (destination) to allow access to the sample subnets provided by our poster; what do you think of that?

This is great information from the both you, I appreciate it very much. I knew there is probably a cleaner way to write out the rules I just don't have the experience with it, been looking at iptables for all of 2 weeks now.

My next hope was that the OP would say one of

• Yes, I see that
• I don't understand what you say
• No, you are wrong because you have overlooked...

(or maybe, "I had also wanted to do ... does that change things?")

from that I was hoping to go on to adding the 'one subnet' filtering. But, in general, the approach of yours seems workable, but I'd like to start from a reasonably neat set of rules to avoid doing it twice. So, you are right that I hadn't solved the problem the OP had asked about, but then I hadn't expected this to be the last word, and, anyway if the OP was in such a hurry that this wasn't fast enough, all the information was in the thread somewhere. And, it is nice to be able to get the OP to the point that they can work their own problems, right?

Incidentally, tutorial material on iptables:

• frozentux has pretty much everything, but is more than a bit of light reading
• A primer
• Another simple one
• And a more server-oriented one