I wanna push packets around. Well, I will...
March 3, 2012 11:00 AM   Subscribe

Please help a networking challenged individual with some iptables rules for my silly little LAN setup.

My network looks like:

modem -> N16 running tomatousb and dhcp (with an open wireless network) -> Time Capsule (with its own SSID, protected network, not providing dhcp).

What I'd like to do is have the open wireless network not be able to see anything else on the LAN, and the closed network be able to see everything, including clients on the open network. There are some tutorials involving setting up subnets and firewall rules for similar things, but I have been unable to understand them enough to modify them to fit my needs.

Where I am so far: By default, no matter where the clients connect from, they are connected to the same interface (br0). However, tomato has an AP Isolation feature, and when I turn this on, clients on the open network connect on eth1, everything else remains on br0. Unfortunately, the isolation only prevents clients on eth1 from seeing other eth1 clients, they can still see things on br0.

My instinct is that a iptables rule or two would fix this up, now that things are on separate interfaces, but I'm fail at figuring it out. Can you help me out? The ideal solution would have things from br0 still able to see and communicate with eth1, but not vice-versa, but if that's difficult, complicated, or impossible, I'm OK with complete separation of the two interfaces.
posted by [@I][:+:][@I] to Computers & Internet (5 answers total) 1 user marked this as a favorite
 
Put the guest network on its own subnet.

In Cisco terms I would write an ACL like this (in pseudo easy to get terms, not actual configuration)

Permit UDP from the guest subnet to reach my DNS server
Permit DHCP from the guest subnet to reach my dhcp server
Deny the guest subnet to 192.168.0.0/24
Deny the guest subnet to
10/8
Deny the guest subnet to
172.16/15
Permit ip any any

This in effect says "you can reach my DNS and DHCP server, but nothing else on my private network"
posted by roboton666 at 11:10 AM on March 3, 2012


Best answer: I think you want to add the following rules. Order matters:
#packets coming from br0 to eth1 are fine
iptables -A INPUT -i br0 -o eth1 -j ACCEPT
#packets from eth1 to br0 are OK if part of an existing
# conversation, that is, responses to br0 from eth1
iptables -A INPUT -i eth1 -o br0 -m state --state RELATED,ESTABLISHED -j ACCEPT
#packets not covered by the above are dropped
iptables -A INPUT -i eth1 -o br0 -j DROP

posted by axiom at 11:28 AM on March 3, 2012 [1 favorite]


Response by poster: Thanks, axiom that seems to work like a charm!

I put one laptop on br0 and another on eth1 and could ssh from br0 to eth1 but not vice versa.

Pings from eth1 can still see things on br0, but I suppose that's a thing of ICMP being separate from this stuff. I don't mind that, but I am curious if there's further rules that could hide pings, or if that's a whole separate area.
posted by [@I][:+:][@I] at 3:22 PM on March 3, 2012


Pings should not be getting through assuming your default (catch-all) policy on INPUT is DROP and you're explicitly enumerating what can go out (via the FORWARD chain, most likely). This is the safest configuration approach to use, but it does mean you'll have to explicitly call out what's allowed. You want to make the last rule you add to INPUT be just:
iptables -A INPUT -i eth1 -j DROP
You can explicitly drop just ICMP or UDP or whatever with the -p flag, like so:
iptables -A INPUT -i eth1 -p icmp -j DROP

posted by axiom at 8:37 PM on March 3, 2012


Favourited for the title only :).
posted by Juffo-Wup at 9:37 PM on March 9, 2012


« Older Tree pit mitigation strategies?   |   Jobless Twentysomething Newer »
This thread is closed to new comments.