Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have an always-on machine running Debian/Squeeze with a couple of ethernet ports (it's doing various serverish jobs, including DHCP) and a LAN on each.

eth0 is on 192.168.7.* and has access to the internet (and the rest of the "office LAN") via a gateway (NAT-translating DSL router) on that LAN at 192.168.7.1.

eth1 is on 192.168.1.* . I'm looking for a quick, easy and Debian-friendly way of configuring the machine so that anyone on the 192.168.1.* LAN only has access to the external internet, DHCP, and can't access any of the other stuff on 192.168.7.*.

I'm sure this is possible using an appropriate set of iptables rules. Suspect I'm looking for one of:

  • A simple guide to how to set up iptables to achieve the above (I can't be the first person to want to do this).
  • A pointer to some user-friendly firewall configuring software which can do this (although note that I don't want to lock down the eth0-side and the 192.168.7.* network at all).
  • Suggestion of some software which is designed to do exactly this; I have an idea there are some packages intended to achieve similar to what I want for internet cafes etc, but I'm not sure where to start looking or whether these might be overkill.

Any tools being in Debian Squeeze (or Wheezy) already is a big plus.

share|improve this question
add comment

1 Answer

up vote 2 down vote accepted

This is fairly easy to do with iptables. In the below, 'wan-iface' is the interface that your WAN connection is on. Depending on how its connected, could be eth2, ppp0, etc. Also, note that you can rename Ethernet interfaces by editing /etc/udev/rules.d/70-persistent-net.rules—highly recommended when you have several. -i lan is much clearer than -i eth0.

You can write an init.d script to apply these rules at boot or use the iptables-persistent package. Or there are various firewall rule generators packaged (personally, I write iptables rules directly, as I often want to do weird things).

You'll need a NAT rule, if your existing one doesn't already cover it:

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o wan-iface -j SNAT --to-source external-ip

External-ip is your actual IP address. If you have a dynamic one, change that line to:

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o wan-iface -j MASQUERADE

Then you'll need a firewall rule to allow the traffic. I'm giving two here, depending on whether your default for forward is DROP or not. It should be drop, but...

iptables -A FORWARD -i eth1 -o wan-iface -j ACCEPT # default is drop
iptables -A FORWARD -i eth1 ! -o wan-iface -j DROP # default is accept

Now, you just need to allow DHCP. Assuming your firewall is running DHCP, and that DNS is on the WAN (else, you'll need to allow them to talk to the DNS server):

iptables -A INPUT -i eth1 -p udp --dport bootps -j ACCEPT
iptables -A INPUT -i eth0 -j DROP # only if your default isn't drop

That's, I believe, the minimal config for this. You can additionally limit what traffic goes out to the Internet. For example, if you wanted web browsing only, instead of the FORWARD rules above, you'd do this (again assuming DNS on the WAN):

iptables -A FORWARD -i eth1 -o wan-iface -p tcp --dport domain -j ACCEPT
iptables -A FORWARD -i eth1 -o wan-iface -p udp --dport domain -j ACCEPT
iptables -A FORWARD -i eth1 -o wan-iface -p tcp --dport http -j ACCEPT
iptables -A FORWARD -i eth1 -o wan-iface -p tcp --dport https -j ACCEPT
iptables -A FORWARD -i eth1 -j DROP # only if default is accept

Note that the above allows three ports, domain (both TCP and UDP, for DNS), http (TCP), and https (TCP).

edit:

In response to your clarification:

It sounds like no NAT is currently taking place on this box. Also, there is no WAN interface, traffic goes out over the LAN. Not the best setup, but doable.

I'll use "lan-ip" to mean the IP address of the Debian box on your LAN (eth0). I'll use "guest-ip" to mean the IP address of the same box on your guest network (eth1).

I'm getting confused by your interface naming while writing this, so I'm going to assume you take my advice and rename the interfaces to "lan" (eth0) and "guest" (eth1). If not, you can do a find & replace.

It doesn't sound like you currently have routing or firewalling set up on this box, so I'll give full rules, not just the ones to add. You may need to add some more, of course.

You'll need to turn on IP forwarding (edit /etc/sysctl.conf to do so). And turn on reverse path filter in the same file.

You will need to configure DHCP to offer service on your eth1 network. Please note the default gateway it servers out (for the eth1 guest network only) will need to be guest-ip, not 192.168.7.1.

Your NAT rule will look a little different. It'd be preferable not to have this, and instead perform this on 192.168.7.1, but I'm going to guess that's not possible. If it is possible, skip this nat rule, add it on 7.1 instead, and add a route to 192.168.1.0/24 via lan-ip.

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o lan -j SNAT --to-source lan-ip

now, since you don't have a firewall set up currently, default things to deny. This is the most secure way to do things, generally.

iptables -P INPUT DROP    # default for traffic to firewall (this box)
iptables -P FORWARD DROP  # default for forwarded traffic
iptables -F               # clear rules
iptables -X               # delete custom chains
iptables -t nat -F        # same, but for nat table
iptables -t nat -X

iptables -A INPUT -i lo -j ACCEPT  # let the box talk to itself. Important.

At this point, your box will be completely inaccessible. Not what you want. The next few rules fix that. The first two set up connection tracking, allowing packets that are part of an existing connection (or very closely related to it)

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

Then we'll assume for now that you trust the machines on the office LAN, and allow all traffic from them. You could change this to more restricted rules if you'd like. Note the FORWARD rule will allow you to access machines on the guest network from the office LAN. If that isn't desired, omit it.

iptables -A INPUT   -i lan          -j ACCEPT
iptables -A FORWARD -i lan -o guest -j ACCEPT

Now, to allow some traffic from the guest network. First, you'll need to allow DHCP.

iptables -A INPUT -i guest -p udp --dport bootps -j ACCEPT # dhcp

Next, I assume you don't want to allow the guest access to any of your private networks. So we'll just drop all guest traffic to RFC1918 (private) space.

iptables -A FORWARD -i guest -d 10.0.0.0/8      -j DROP  
iptables -A FORWARD -i guest -d 172.16.0.0/12   -j DROP
iptables -A FORWARD -i guest -d 192.168.0.0/16  -j DROP

Since we've dropped all private address space, the rest is public. So allow it. This line is somewhat scary, as if one of the previous lines were to go missing, it'd be trouble.

iptables -A FORWARD -i guest -o lan -j ACCEPT

You could of course limit that to specific protocols and ports (as in the web browsing only example).

You can also add rules for logging dropped packets, etc.

share|improve this answer
    
Ah, sorry, misunderstanding: the WAN (internet) gateway is a (NAT-translating) router at 192.168.7.1 and my DHCP server (which is on the Debian box, not the router) tells everyone that (the DHCP also tells everyone to use my ISP's DNS servers directly). There isn't some "eth2" or "ppp0" I haven't mentioned. –  timday Aug 23 '12 at 11:03
    
@timday updated in response to your clarification –  derobert Aug 23 '12 at 20:29
    
Thanks, thats great; yes all your assumptions are basically correct (sorry, hadn't realized just how many variables there actually are here) and this looks very useful and sensible setup. Will be trying it out once an order of some networking kit for the eth1 side arrives... –  timday Aug 25 '12 at 10:12
    
Yes this is in place and working nicely (the NAT is actually done by the router so I just skipped that stuff). I did throw in an extra line to allow ssh from guest-to-lan which might be handy at times. The acid test was nmap runs from machines on each of the subnets to the two lans; confirms the desired behaviour. –  timday Sep 3 '12 at 12:39
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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