Grant Taylor wrote: > On 11/02/07 15:24, Corey Hickey wrote: >> 1. Check /proc/sys/net/ipv4/ip_forward on box A1 to see if it's >> configured to route at all. >> >> 2. The hosts on network A will receive packets from miscellaneous IP >> addresses in B's subnet, and not have any idea what to do with them. >> You'll need to either configure routes on the hosts in network A... >> >> # ip route add 10.3.0.0/16 via 192.168.4.10 dev eth0 >> >> ...or set up box A1 to SNAT packets >> >> # iptables -t nat -A POSTROUTING -s 10.3.0.0/16 -d 192.168.4.0/24 -j >> SNAT --to-source 192.168.4.10 >> >> You'll have to do something similar for the reverse direction, too. > > You could do either of the above. I meant to do both, which I think is necessary in order to make the OPs proposed scheme work without modification. I'll defer if I'm wrong, though--I haven't tested it, and, as you said in your other email, it's "a very weird scenario." > However there should be a route from any box on either network to > specific boxes on the other network. Remember that the OP configured > routes on AR and BR to reach host(s) on Net B and Net A (respectively) > via A1. Thus when a host on Net B receives a packet from a host on Net > A, it will reply via its default gateway, BR. BR will then redirect or > route the packet back to A1 which will then send the packet directly on > to the original host on Net A. This is all of course presuming that A1 > is forwarding packets like it needs to be and that there are no > firewalls in place blocking any thing, especially reverse path filters. I don't think this will work unless BR has a route like: # ip route add 192.168.4.0/24 via 10.3.0.13 dev eth0 ...whereas the OP only specified wanting routes to a few specific machines rather than the whole networks. In any case, debating that is probably academic, since I agree with you in principle. It should be cleaner to set up routes for the whole networks and use iptables rules on A1 to only allow traffic to/from specified hosts. There are certainly different ways to do it, and I furthermore agree with you that using a separate link between AR and BR (as you suggested in your earlier message) is cleaner still. I prefer bridging in this situation mostly because it distributes traffic and reduces the load on the routers. >> I haven't tested what I wrote above; if it doesn't work, run tcpdump >> in various places to see what icmp packets are going where. > > TCPDump / Etherial is your *FRIEND*!!! :) >> Honestly, though, I think you're setting yourself up for a decent >> headache trying to do it this way. In my opinion, the easy solution >> is in the first word of your subject line: just make host A1 a >> bridge. That's what I did when I originally set up that box, and it >> worked fine the whole time I managed it (actually, I didn't manage it >> at all, since the bridging never had any problems). > > Bridging and / or proxy ARP by them selves will not solve this problem. > Net A and Net B have different IP address ranges, thus even with a > bridge in place the hosts will never communicate. In fact a bridge with > out any thing else will just worsen the situation by passing broadcasts > where they are not needed. Absolutely. >> Put both physical networks on the same IP subnet and enforce any >> desired firewalling/segmentation with a few simple iptables rules >> running on the bridge. If you're still using the same machine that >> used to do that job, you might be able to find the relevant >> configuration files lying around. If not, I'm sure I can recall at >> least most of the details. > > Ugh. I'm going to presume that the networks have different IP address > ranges and are not presently joined for a reason. Thus combining the IP > address ranges and bridging them together will actually be a regression > in network config / technology / evolution. The two networks in question are rather small and occupy adjoining buildings. Network A had to be rebuilt after getting torn out while the corresponding building underwent a very intrusive retrofit and remodeling. Prior to that, the two networks were bridged and shared the same subnet. I don't know if the OP has a reason to isolate them from each other now. I guess I'll go ahead and describe the former setup in a little detail. Every host in the entire bridged network was given an IP address within the subnet 10.0.0.0/8. The bridge was configured to drop all DHCP packets, so there was a DHCP server on network A and another on network B. Hosts on network A were given addresses in the following ranges[1]: 10.0.0.0/16 10.1.0.0/16 10.2.0.0/16 Hosts on network B were given addresses in the following range: 10.3.0.0/16 ...but, regardless of which network a host was on, it still was given the /8 subnet, so hosts could communicate over the bridge without any further configuration. Since each network had its own router to the Internet, the DHCP servers also specified separate gateways. The bridge was configured to drop packets with sources or destinations that didn't match the IP ranges corresponding to the source/destination networks[2]. That's all. My philosophy was to allow unrestricted communication over the bridge and gently LART users that caused trouble (always inadvertently; Windows worms and such). If the OP wants to allow communication only to a few hosts, that's no more difficult--just write a few rules to accept desired traffic and then drop/reject the rest. [1] Given the chance to do it over, I would have allocated addresses to network A from 10.0.0.0/18 and network B from 10.4.0.0/18 in order to simplify a little bit. Also, I should mention that the use of several /16 ranges doesn't mean we had anywhere near that many hosts; the separation was just for management. [2] Just in case some users on network B tried to manually set their IP address and gateway in order to use the better Internet access of network A. Of course, they could still have tunneled through the bridge to an accomplice on network A, but they could have also used an accomplice's wireless router, or CAT-5 strung between rooftops, or RFC 1149, etc. I dealt with such things on a case-by-case basis. :) -Corey _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
