Yes, you are right. After I posted that message, I realized I left out some parts that are probably not obvious enough to be left out. Packets originating at the DMZ going out will be routed correctly. No addtional work needs to be done to fix that. However, the return packets on those connections need to be identified and MARKed with value 1. It's important to take note that almost all packets are going to be MARKed already, since it is after all the DMZ. The real problem is connections originating from the router. The return packets on these connections will get forwarded to the DMZ. Now this may not be a problem at all, if you you don't want your router to be accessed from the outside world. In fact, we can take a page from software developers around the world and call this a feature. The device operates transparently by default :P The work around for this is rather complex and requires an additional interface on the private network side (using 192.168.0.24 in this example) as well as a kernel patch. The general idea is this, first we add a rule to the OUTPUT chain. iptables -t mangle -A OUTPUT -j MARK --set-mark 2 All localy generated traffic will have a MARK of value 2. Now we must create another routing table called looper. Add the correct rule to lookup the table. ip rule add fwmark 2 lookup looper. We then take advantage of iproute's dummy nat. ip rule add nat 192.168.0.24 fwmark 2 (Since we push rules on to the top of the rule list, we have to do it in this order.) In the looper table we need to put two routes. First the network route for the internal network, and second the default gateway. There is one very important item in these routes, and that is, we are specifying our new interface (eth2). ip route add 192.168.0.0/24 dev eth2 src 192.168.0.24 table looper ip route add default via 192.168.0.1 dev eth2 table looper That's it for the routing and firewall rules. Now you need to rebuild the kernel, after patching it with the send-to-self patch. This patch will allow you to talk from 192.168.0.24 to 192.168.0.1 over the wire instead of internally through the kernel. I'm not 100% sure that you need to send the packet out over the wire. The deciding factor is whether or not the packet will pass through the POSTROUTING chain. If it does, it may be possible to eliminate the second interface all together. If you decide to eliminate the interface and give it a try, keep in mind you need to change the mark on the packet. This will do: # Uncomment only if you are not using a third interface #iptables -t mangle -A PREROUTING -m mark --mark 2 -j MARK --set-mark 0 Load up the new kernel. Add two lines to your firewall script: echo 1 > /proc/sys/net/ipv4/conf/eth1/loop echo 1 > /proc/sys/net/ipv4/conf/eth2/loop And there you have it. Wow, what a mess. I guess it could be worse... it could look like my routing setup :P One more thing, on the DMZ client you have to specify the gateway as 192.168.0.1 and add a route into the routing table for 192.168.0.0/24. You might also have to make a few exceptions in the firewall if you have rules to prevent spoofing. I hope that covers it all, Matt ----- Original Message ----- From: "Taylor, Grant" <gtaylor@xxxxxxxxxxxxxxxxx> Date: Wednesday, June 22, 2005 5:33 pm Subject: Re: Q: Routing the Same IP simultaneously on different computers ? > Matt this is a very interesting idea, along the lines of a > solution that I did not want to try to get strait in my head. The > question that I run in to is how does the system handle returning > (outbound) internet traffic from systems not in the DMZ? The way > that I read and understand your idea I can't tell how the > returning traffic will not be sent to the DMZ. Other than that I > think this idea is a very good one. > > The idea that comes to my mind, but sadly will not work as I know > it, is to use EBTables to bridge the internet and LAN interface > and use the EBTables brouting table BROUTING chain to decide if > the traffic should be bridged or not based on a connection > tracking state, i.e. if the traffic is not related to any outbound > LAN traffic then bridge the traffic over to the DMZ server, if it > is related DROP the traffic in the BROUTING table which causes it > to be routed. You would obviously need to have at least an > aliased interface on the LAN interface to do the routing with. > But I don't know of any match extension for EBTables that will > test based on whether or not the NetFilter Connection Tracking > code has seen the traffic or not. However I think this would be a > useful match extension, and guessing I don't think it would be > hard to write though I am not qualified to do so or really speculate. > > > > Grant. . . . _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
