Not normally a question for this group, but you guys are very bridge/router/firewall savvy, so I thought I''d toss it here. I have a bridge. On one side of the bridge is that fancy thing called the Internet. On the other side is my LAN. The bridge is the obvious demarcation line and a good place to put a firewall. Now, I have all my iptables stuff planned out, EXCEPT for nat. The usual way to do NAT: iptables -A POSTROUTING -t nat -s $INTERNAL_NET -j MASQUERADE iptables -A FORWARD -j ACCEPT Now, the problem I have is that my LAN is mixed NAT''d addresses and routable IPs. I have a host of FORWARD rules to determine which packets get sent onto which servers (routable IPs). My worry is that if I put in the "iptables -A FORWARD -j ACCEPT" it''ll defeat the whole purpose of those entries. My question is: How do I set up a FORWARD for JUST the NATed packets without touching the non-NATed packets? Would a -d to my internal network ($INTERNAL_NET is set to 192.168.10.0/24) do it? IE would this work: iptables -A POSTROUTING -t nat -s $INTERNAL_NET -j MASQUERADE iptables -A FORWARD -d $INTERNAL_NET -j ACCEPT Also, if I post up my iptables entries/script, can someone help me proof them for problems? ----- Michael Yacht CTO Ideal Conditions, Inc. 5329 Beeler Street, #2 Pittsburgh, PA 15217 v: 412-325-1375
ICI Support wrote:> Now, the problem I have is that my LAN is mixed NAT''d addresses and routable > IPs. I have a host of FORWARD rules to determine which packets get sent > onto which servers (routable IPs). My worry is that if I put in the > "iptables -A FORWARD -j ACCEPT" it''ll defeat the whole purpose of those > entries. > > My question is: How do I set up a FORWARD for JUST the NATed packets > without touching the non-NATed packets? Would a -d to my internal network > ($INTERNAL_NET is set to 192.168.10.0/24) do it? > > IE would this work: > > iptables -A POSTROUTING -t nat -s $INTERNAL_NET -j MASQUERADE > > iptables -A FORWARD -d $INTERNAL_NET -j ACCEPTIf I tested this properly, it does seem to work. You could follow the command above with whatever rules jumping to ACCEPT you want, ending with a REJECT for whatever you don''t want (or set the policy for FORWARD to REJECT). There are some other ways to do it. May I ask why this machine is a bridge? My guess is that you have something like this: [Internet] ----> T1 router ----> Linux bridge ----> LAN ...wherein the T1 router handles the routing to/from your public IPs and your bridge handles the routing (with NAT) from your private IPs.> Also, if I post up my iptables entries/script, can someone help me proof > them for problems?Sure; it couldn''t hurt, unless someone nasty sees a flaw and tries to attack one of your systems through it. :) I''m going to be gone for several days, but I''ll look at it when I get back. Somebody else might look, too. -Corey
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. 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: -------------------------- # Do some initialization: # Clear out the current settings: iptables --flush iptables -t nat --flush iptables -t mangle --flush iptables --delete-chain iptables -t nat --delete-chain iptables -t mangle --delete-chain #--------------------------------------------------------------- # If a packet doesn''t match one of the built in chains, then # The policy should be to drop it #--------------------------------------------------------------- iptables --policy INPUT DROP iptables --policy OUTPUT DROP iptables --policy FORWARD DROP # Loopback accepts all: iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # Define some global variables: # First define the interfaces EXTERNAL_INT="eth0" INTERNAL_INT="eth1" # Now the machines on the inside. BRIDGE_IP="70.89.224.61" TESTBOX_IP="70.89.224.60" WIN2K_IP="70.89.224.59" MEATNOG_IP="70.89.224.58" ICI_IP="70.89.224.57" INTERNAL_NET="192.168.10.0/24" # AEGIS''s Firewall, going to accept all from this one. AEGIS_IP="12.39.123.5" # NAT iptables -A POSTROUTING -t nat -o eth0 -s $INTERNAL_NET -d 0/0 -j MASQUERADE iptables -A FORWARD -d $INTERNAL_NET -j ACCEPT sysctl -w net.ipv4.ip_forward=1 echo 1 > /proc/sys/net/ipv4/ip_forward # Allow all outgoing packets. May want to filter this later. iptables -A OUTPUT -o eth0 -j ACCEPT # 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 # Let AEGIS reach the Win2k box. iptables -A FORWARD -i eth0 -s $AEGIS_IP -d $WIN2K_IP -j ACCEPT # SSH Access: # SSH is on port 22, TCP iptables -A FORWARD -i eth0 -s 0/0 -d $MEATNOG_IP -p TCP --dport 22 -j ACCEPT iptables -A FORWARD -i eth0 -s 0/0 -d $ICI_IP -p TCP --dport 22 -j ACCEPT # SMTP Access: # SMTP is on port 25, TCP iptables -A FORWARD -i eth0 -s 0/0 -d $MEATNOG_IP -p TCP --dport 25 -j ACCEPT iptables -A FORWARD -i eth0 -s 0/0 -d $ICI_IP -p TCP --dport 25 -j ACCEPT # DNS Access: # DNS is on port 53, TCP/UDP iptables -A FORWARD -i eth0 -s 0/0 -d $MEATNOG_IP -p TCP --dport 53 -j ACCEPT iptables -A FORWARD -i eth0 -s 0/0 -d $MEATNOG_IP -p UDP --dport 53 -j ACCEPT iptables -A FORWARD -i eth0 -s 0/0 -d $ICI_IP -p TCP --dport 53 -j ACCEPT iptables -A FORWARD -i eth0 -s 0/0 -d $ICI_IP -p UDP --dport 53 -j ACCEPT # HTTP Access: # HTTP is on port 80 iptables -A FORWARD -i eth0 -s 0/0 -d $MEATNOG_IP -p TCP --dport 80 -j ACCEPT iptables -A FORWARD -i eth0 -s 0/0 -d $ICI_IP -p TCP --dport 80 -j ACCEPT iptables -A FORWARD -i eth0 -s 0/0 -d $WIN2K_IP -p TCP --dport 80 -j ACCEPT # POP3 Access: # POP3 is on port 110 iptables -A FORWARD -i eth0 -s 0/0 -d $MEATNOG_IP -p TCP --dport 110 -j ACCEPT iptables -A FORWARD -i eth0 -s 0/0 -d $ICI_IP -p TCP --dport 110 -j ACCEPT # AUTH Access: # AUTH is on port 113. iptables -A FORWARD -i eth0 -s 0/0 -d $MEATNOG_IP -p TCP --dport 113 -j ACCEPT iptables -A FORWARD -i eth0 -s 0/0 -d $ICI_IP -p TCP --dport 113 -j ACCEPT # MUD Access: # The Mud is on port 6250 iptables -A FORWARD -i eth0 -s 0/0 -d $MEATNOG_IP -p TCP --dport 6250 -j ACCEPT -----Original Message----- From: lartc-bounces@mailman.ds9a.nl [mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of Corey Hickey Sent: Wednesday, September 21, 2005 1:27 PM To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] IP Tables on a bridge ICI Support wrote:> Now, the problem I have is that my LAN is mixed NAT''d addresses androutable> IPs. I have a host of FORWARD rules to determine which packets get sent > onto which servers (routable IPs). My worry is that if I put in the > "iptables -A FORWARD -j ACCEPT" it''ll defeat the whole purpose of those > entries. > > My question is: How do I set up a FORWARD for JUST the NATed packets > without touching the non-NATed packets? Would a -d to my internalnetwork> ($INTERNAL_NET is set to 192.168.10.0/24) do it? > > IE would this work: > > iptables -A POSTROUTING -t nat -s $INTERNAL_NET -j MASQUERADE > > iptables -A FORWARD -d $INTERNAL_NET -j ACCEPTIf I tested this properly, it does seem to work. You could follow the command above with whatever rules jumping to ACCEPT you want, ending with a REJECT for whatever you don''t want (or set the policy for FORWARD to REJECT). There are some other ways to do it. May I ask why this machine is a bridge? My guess is that you have something like this: [Internet] ----> T1 router ----> Linux bridge ----> LAN ...wherein the T1 router handles the routing to/from your public IPs and your bridge handles the routing (with NAT) from your private IPs.> Also, if I post up my iptables entries/script, can someone help me proof > them for problems?Sure; it couldn''t hurt, unless someone nasty sees a flaw and tries to attack one of your systems through it. :) I''m going to be gone for several days, but I''ll look at it when I get back. Somebody else might look, too. -Corey _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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_forwardDon''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
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@mailman.ds9a.nl [mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of Corey Hickey Sent: Wednesday, September 21, 2005 3:35 PM To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] 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 appreciateit.> 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 -jMASQUERADE "-d 0/0" is unnecessary, as that is the default.> sysctl -w net.ipv4.ip_forward=1 > echo 1 > /proc/sys/net/ipv4/ip_forwardDon''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@mailman.ds9a.nl mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
ICI Support wrote:> I have a bridge. On one side of the bridge is that fancy thing called the > Internet. On the other side is my LAN. The bridge is the obvious > demarcation line and a good place to put a firewall.*nod*> Now, I have all my iptables stuff planned out, EXCEPT for nat. > > The usual way to do NAT: > > iptables -A POSTROUTING -t nat -s $INTERNAL_NET -j MASQUERADE > > iptables -A FORWARD -j ACCEPT > > Now, the problem I have is that my LAN is mixed NAT''d addresses and routable > IPs. I have a host of FORWARD rules to determine which packets get sent > onto which servers (routable IPs). My worry is that if I put in the > "iptables -A FORWARD -j ACCEPT" it''ll defeat the whole purpose of those > entries.Put the (new) rules in question below the other rules that you have in place now.> My question is: How do I set up a FORWARD for JUST the NATed packets > without touching the non-NATed packets? Would a -d to my internal network > ($INTERNAL_NET is set to 192.168.10.0/24) do it? > > IE would this work: > > iptables -A POSTROUTING -t nat -s $INTERNAL_NET -j MASQUERADE > > iptables -A FORWARD -d $INTERNAL_NET -j ACCEPTYes this should work.> Also, if I post up my iptables entries/script, can someone help me proof > them for problems?Sure (but others have and I have not looked at it yet). I question why you don''t do this as a Bridging Router? I know that you have said (in another email) that you have concerns over using a BRouter. (I think) This would be quite easy to do as a BRouter. To do so you would bridge your external and internal interfaces together and set up a rule such that any traffic coming in to the internal interface with a source IP from you NAT clients to be routed via IPtables. I would issue a series of commands like this: ----- # Set up some basic interface settings. ifconfig $INet 0.0.0.0 up ifconfig $LAN 0.0.0.0 up # Let''s establish our bridge. (I like the name bri0 better than br0 but it makes no difference.) brctl addbr bri0 brctl addif bri0 $INet brctl addif bri0 $LAN # Let''s set up our bridge interface with external and internal IPs so we can NAT / route for the LAN. ifconfig bri0.1 $INet_BRouter_IP ifconfig bri0.2 $LAN_Router_IP # Let''s turn our bridge in to a bridging router by telling the bridge which packets it should NOT bridge and thus route. ebtables -t BROUTE -A BROUTING -i $LAN -s $LAN_Subnet -j DROP # Put your IPTables lines here like you normally would. ----- This is just test and theoretical code but it should work for you. If you compiled in support for "Bridged IP/ARP packets filtering" (as called per 2.6.13) you will have to enable forwarding support for the traffic coming in the bri0 interface that will be going back out the bri0 interface. "Bridged IP/ARP packets filtering" is (as I understand it) the extension that allows IPTables to see the traffic that would be passing through the bridge thus allowing you to do many of the things that IPTables can do on a Layer 2 bridge / firewall. # Accept bridged traffic that is coming in from the internet and going out to the LAN. iptables -t filter -A FORWARD -i bri0 -o bri0 -m physdev --physdev-is-bridged --physdev-in $INet --physdev-out $LAN -j ACCEPT # Accept bridged traffic that is coming in from the LAN and going out to the internet. iptables -t filter -A FORWARD -i bri0 -o bri0 -m physdev --physdev-is-bridged --physdev-in $LAN --physdev-out $INet -j ACCEPT # Accept traffic that is destined to one of the IPs assigned to the bri0 interface. iptables -t filter -A FORWARD -i bri0 -o bri0 -d $INet_BRouter_IP -m physdev --physdev-is-in -j ACCEPT iptables -t filter -A FORWARD -i bri0 -o bri0 -d $LAN_IP -m physdev --physdev-is-in -j ACCEPT # Accept traffic that is from one of the IPs assigned to the bri0 interface. iptables -t filter -A FORWARD -i bri0 -o bri0 -s $INet_BRouter_IP -m physdev --physdev-is-out -j ACCEPT iptables -t filter -A FORWARD -i bri0 -o bri0 -s $LAN_IP -m physdev --physdev-is-out -j ACCEPT # Note: I''m not 100% sure about the --physdev-is-in and --physdev-is-out. They may be backwards so play with them. Of course if you just set a default policy of ACCEPT on the FORWARD chain then everything should get through unless you explicitly block it. Would any one else care to checksum my thought proccess? Please? Grant. . . .