Well after the holidays I finally managed to test this setup properly. Unfortunately the results were less then encouraging. :( The problem before seemed to be the proxy arp responding to arp requests with the MAC address of the wrong interface. (most likely because of the physical network layout) So I plugged our ADSL modem directly in to the firewall, then our local hub in to the second interface in the firewall (how it should be). Enabled proxy arp for all interfaces, and ip forwarding, then I watched the arp cache as I tried to ping different IPs. Before I even got a chance to ping the different IPs though, the arp cache was filling up with entries such as: [ETH0 is local, ETH1 is internet] ? (207.102.201.187) at 00:60:94:D7:B6:9F [ether] on eth0 ? (207.102.201.188) at 00:50:BF:0F:AB:54 [ether] on eth0 ? (207.102.201.190) at 00:C0:49:17:0E:A5 [ether] on eth1 ? (207.102.201.169) at 00:50:BF:0F:B2:0B [ether] on eth0 ? (207.102.201.174) at <incomplete> [ether] on eth0 ? (207.102.201.164) at 00:50:BF:06:4F:A6 [ether] on eth0 When I did try pinging an IP, from the inside, or over the internet I would see the IP in the arp cache, but the MAC address was _always_ different, and sometimes would show "incomplete". I was under the impression with proxy arp, that the firewall would respond with the MAC address from its external interface to all IPs matching the subnet? (all 207.102.201. IPs matching 255.255.255.224?) So at the very least the packets would get to the firewall so they can be handled by a magical IPTable rule? If this was working properly wouldn't the arp cache look something like this: MAC address of the internet interface in the firewall: 00:c0:35:h7:0h:55 ? (207.102.201.187) at 00:c0:35:h7:0h:55 [ether] on eth1 ? (207.102.201.188) at 00:c0:35:h7:0h:55 [ether] on eth1 ? (207.102.201.169) at 00:c0:35:h7:0h:55 [ether] on eth1 ? (207.102.201.174) at 00:c0:35:h7:0h:55 [ether] on eth1 ? (207.102.201.164) at 00:c0:35:h7:0h:55 [ether] on eth1 Heres my routing table: Destination Gateway Genmask Flags Metric Ref Use Iface 207.102.201.160 * 255.255.255.224 U 0 0 0 eth1 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default 207.102.201.19 0 0.0.0.0 UG 0 0 0 eth1 I'm pretty much shooting in the dark here, and I'm not even sure if I fully understand this entire concept with proxy arp. A step by step howto sure would be nice, it seems most of the Firewall-HOWTO or IPMasq-HOWTO just touch on the basic concept, but don't go in to much detail. To me if I IP-aliased each IP on the firewall, some fancy IPTable rules should be able to take care of the rest. I've had this working but unfortunately netmeeting only works for sending, not receiving voice. Everything else seems to work top notch, but allowing netmeeting to all 30 computers is the whole point of this firewall. ;) Any help would be greatly appreciated. Thanks. At 07:01 AM 12/21/00 +0000, you wrote: >Mike Benoit wrote: > > > Maybe I'm misinformed, will a setup such as this even work? > > > > I had the machine strangely plugged in to the network when I did my > > testing, so its quite possible that it was using the internal network. > Even > > though the test client had an external IP from which I was testing. But > > will this work from the external interface? > > > > My understanding is that the firewall will reply to arp requests for each > > (30) external IP address we have with its own MAC address, thus tricking > > computers on the internet in to sending packets destined for any of our > > external IPs to our firewall. From there the firewall can route the > packets > > to each client behind it with little difficulty? > >Note that: > >1. The firewall's routing tables must be correct with regard to the >destination IP address. > >2. The source and destination must be on opposite sides of the >firewall in order for the firewall to be able to do anything about it. > > > Does this sound plausible to you? Or do you know of a better way to > setup a > > firewall that wont cause problems with such applications like netmeeting? > > Thanks. > >Also note that you can usually[1] do without proxy-ARP; it just means that you >have to propagate more complex routing information. > >[1] but not if you have a host whose routing table can't be changed >(e.g. an ISP-supplied router). > >-- >Glynn Clements <glynn@sensei.co.uk> >- >: send the line "unsubscribe linux-net" in >the body of a message to majordomo@vger.kernel.org - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
