Interesting idea, Corey. I'll consider it. It is the split-horizon DNS that concerns me and has stopped me from doing that already. Plus then turning the bridge into a brouter too. Thankfully there isn't too much traffic between the local machines and the routable servers. Most of the traffic between them are NetBios-type connections. All my servers have been given local-IP aliases, and services like SMB and WFS are bound to those local-IP aliases (also ensuring that the external IPs can't do those things). Thanks for proofing my script. Glad it looks right. It is the first iptables script I've made. I know a few of the params are unneeded, but I'm a big fan of explicitly setting options. Keeps me sane when I have to go back and look at them 6 months later. Also, don't get me started about ISP tech support. My ISP is Comcast and half the time I feel like I am educating them whenever I call. The whole reason I'm doing this (moving the firewall from the router/modem to the bridge) is because I was told that the modem is sometimes 'unstable' if used as a firewall too. So now I'm trying to reduce that modem down as far as possible to a dumb modem. - Mike -----Original Message----- From: lartc-bounces@xxxxxxxxxxxxxxx [mailto:lartc-bounces@xxxxxxxxxxxxxxx] On Behalf Of Corey Hickey Sent: Wednesday, September 21, 2005 3:35 PM To: lartc@xxxxxxxxxxxxxxx Subject: Re: IP Tables on a bridge ICI Support wrote: > Corey, that is exactly why it is a bridge and precisely my setup, except > that I have a 8M/1M cable modem with 5 static IPs instead of a T1. But, > effectively, it is the same. Back before I knew anything about this stuff my mentor set up a bridge for exactly that reason. We had a setup similar to yours, but probably a bit bigger -- 16 public IPs and around 100 private ones. Trouble was, there was a lot of internal traffic between the public-IP machines and the private-IP machines. Even though the two subnets were on the same physical Ethernet they couldn't talk to each other directly because they had no direct knowledge of each other. Thus, the Linux router was routing all the traffic, which slowed everything down somewhat. Our eventual solution was to take the following steps: 1. Assign the public machines IPs within a certain range of the private-IP subnet _instead_ of directly using a public IP. 2. Assign the internal interface of the SDSL router a private IP in a different range from what we were using for our LAN. Since we were using 10.0.0.0/8 for the LAN, we gave the router 192.168.0.1/24. 3. Likewise for the external interface of the Linux router: 192.168.0.2/24. 4. Set up a static route in the SDSL router to route any packets destined for our public IPs to 192.168.0.2. 5. Set the default route in the Linux router to 192.168.0.1. 6. Set up NATting in the Linux router in such a way that any traffic to the public IPs gets DNATted exclusively to the corresponding private IP, and vice versa for traffic coming from the "special" private IPs. For example: private <---> public 10.1.0.1 <---> 123.123.123.1 10.1.0.2 <---> 123.123.123.2 7. Implement a split-horizon DNS setup so internal clients would get the servers' private addresses and external clients would get the servers' public addresses. Now, I'm not necessarily advocating such a setup to you. There are pros and cons, and I thought you might be interested in knowing of an alternate method. Pro: * Private and "public" machines are on the same subnet. * The lowest IP of your public range no longer needs to be the network address, and is now usable for a host. Con: * 75% of ISP tech support people don't know what to make of it. * Split-horizon DNS can be more complex. > If people could proof/suggest/comment on the script, I would appreciate it. > This is my first time using iptables. In the past, I had a T1 line and I > used the cisco router as my firewall. > > Below is my script: I've cut out the parts I'm not commenting on. > # NAT > iptables -A POSTROUTING -t nat -o eth0 -s $INTERNAL_NET -d 0/0 -j MASQUERADE "-d 0/0" is unnecessary, as that is the default. > sysctl -w net.ipv4.ip_forward=1 > echo 1 > /proc/sys/net/ipv4/ip_forward Don't these do the same thing? I've always just used echo. > # All internal IPs are assumed to be trusted. > iptables -A INPUT -j ACCEPT -p all -s 192.168.10.0/24 -i eth1 > iptables -A OUTPUT -j ACCEPT -p all -d 192.168.10.0/24 -o eth1 "-p all" is unnecessary. That's the default. That's pretty much it -- your script is fairly simple and nothing looked wrong to me. One thing that might reduce the load a bit: iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT If you put that rule before your other filter rules, any packet that's part of (or related to) an established connection will be accepted and not have to traverse the rest of your rules. -Corey _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
