Date: Sun, 08 Oct 2000 02:57:28 +0200 From: Bernd Luevelsmeyer <bernd.luevelsmeyer@heitec.net> To: cjclark@alum.mit.edu Cc: questions@FreeBSD.ORG Subject: Re: arp proxy Message-ID: <39DFC678.1BAA1630@heitec.net> References: <39DC78C8.A3CF4F56@heitec.net> <20001005205137.L25121@149.211.6.64.reflexcom.com> <39DDDA7F.68AD47A2@heitec.net> <20001006105442.A62974@149.211.6.64.reflexcom.com> <39DF7F6D.48AEE934@heitec.net> <20001007150209.S25121@149.211.6.64.reflexcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Crist J . Clark wrote: > > On Sat, Oct 07, 2000 at 09:54:21PM +0200, Bernd Luevelsmeyer wrote: > > Crist J . Clark wrote: > [snip] > > Hence I thought, fine, make the gateway answer all ARPs for inside > > addresses from the outside, and the gateway part will be handled by the > > normal gateway functionality. > > Didn't work, however. The ARPs were answered as expected, and the > > packages were sent to the gateway. The gateway however didn't send them > > on, apparently it dropped them. My theory is that the gateway part > > somehow was confused because, from the fumbled ARP table, it assumed > > that all the subnet's addresses were local to the gateway machine > > itself, so sending them out was considered unnecessary. > > How is your routing done to handle this correctly? Currently, because of the bridge, there's no routing at all. What I tried is: The subnet is 193.101.232.0/25, so the gateway's "inner" address would be 193.101.232.1/25, and a route to the subnet would be set up automatically. Since our ISP doesn't particularly care for our gateway's address I'd just set up an arbitrary 192.168/16 address for the "external" interface fxp1 and set up a default gateway of '-iface fxp1'. The subnet's machines would then have a default gateway of 193.101.232.1 . I debugged this, and sending outwards was working as expected. Packets coming from outwards wouldn't work because the arp wasn't answered, as expected. To get the ARP situation right I tried variations of arp -s 193.101.232.10 auto pub or arp -s 193.101.232.10 12:23:34:45:56:67 pub with 193.101.232.10 being a test- and debug-machine attached to the gateway's "inner" interface and 12:23:34:45:56:67 being the gateway's "external" MAC address, the real value of which I no longer remember. I got it so far as to answer the arp requests and getting the outside stuff sent to the gateway (I checked the destination MAC address was in fact the gateway's external MAC, and all sorts of counters showed traffic was in fact coming in, such as 'netstat -i'), but I never managed to let the gateway send the packages further into the inner subnet. Setting or not setting 'arpproxy_all' in /etc/rc.conf didn't have any noticeable effect. [...] > > This was not covered in my original mail, but a NAT wouldn't be > > appropriate in this situation. The subnet's machines are mail servers, > > HTTP proxies and so on. It's much easier if they have publically > > routable addresses of their own; a NAT would give them all the same > > address. > > Not necessarily. See 'redirect_address' in natd(8). You can use all of > your addresses. You are right, I didn't think of the redirect feature. It might well work; however, I don't like the idea of rewriting all the traffic for e.g. the mail server. I think they ought to have their real addresses, or there would be all sorts of problems with IPSec traffic, or the spam filter in the mail server, for example. The client would really talk to the NAT machine, but e.g. the mail server would handle it, itself having an entirely different address that the client doesn't know. Passive connections to the FTP server would have essentially the same problem of a server apparently "not knowing" its own address. Altogether I think while NAT is nice to protect workstations, servers should get their traffic routed to them unmodified. Greetings, Bernd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39DFC678.1BAA1630>