Date: Sat, 07 Oct 2000 21:54:21 +0200 From: Bernd Luevelsmeyer <bernd.luevelsmeyer@heitec.net> To: cjclark@alum.mit.edu, questions@FreeBSD.ORG Subject: Re: arp proxy Message-ID: <39DF7F6D.48AEE934@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Crist J . Clark wrote:
>
> On Fri, Oct 06, 2000 at 03:58:23PM +0200, Bernd Luevelsmeyer wrote:
[...]
> > Hence, I don't desperately need something right now to get the network
> > running, the bridge is operating just fine. I would however like to
> > replace the bridge with an ARP proxy, so I'm interested if FreeBSD is
> > able to work as an ARP proxy at all, and if it is: how. Just enabling
> > 'arpproxy_all' in /etc/rc.conf definitly isn't enough.
>
> Hmmm... I don't think that is what an ARP proxy does (at least not in
> FreeBSD). I can't seem to find docs on it (no docs on a sysctl switch!
> *SHOCK*), so "I'll use the source, Luke."
I'll create a PR about the arp proxy topic; after checking if there is
one already, of course.
> If you track down the proxy code, you will find yourself in,
>
> /usr/src/sys/netinet/if_ether.c
>
> Which has helpful comments like,
>
> /*
> * Don't send proxies for nodes on the same interface
> * as this one came out of, or we'll get into a fight
> * over who claims what Ether address.
> */
Thanks. I'll have a look into the source.
> Huh? But if I am not mistaken, all an ARP proxy is going to do is
> reply to ARP requests... And that does not get you far. You'd still
> need to figure out how to get frames over the bridge or packets over a
> router to the machines behind the firewall.
But isn't that exactly what a gateway does... it receives packages for
its own MAC address but targeted to a remote IP address. It will check
the routing tables and then send the package onwards. So, IMHO if you've
got a gateway then you just need to direct all the packages to it so it
can distribute them, and that's what the ARP proxy is good for.
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.
> I don't have your full email easily accessible, so I may again be
> suggesting something you have already tried or thought of, but is
> there a reason not to use NAT and redirect your addresses to machines
> behind the firewall? (I would venture to guess that if you start
> playing with ARP proxies you would end up building your own NAT system,
> but it will be more work and a kludge compared to just using
> natd(8).)
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. One of these machines is in fact a NAT, and behind that is our
intranet, using 10.0.0.0/8 addresses:
ISP --- gateway --- hub --+-- mail
+-- proxy
+-- web server
+-- (more machines)
+-- NAT -- (internal network)
'gateway' is the would-be ARP proxy, and currently a bridge.
The problem is, as stated, that our ISP insists on accessing our public
machines directly, without routing their addresses to 'gateway'.
Therefore, I thought an ARP proxy on the gateway would be fine.
We also don't have a default gateway at our ISP but are supposed to act
as if any machine on the internet were directly accessible (I suppose
the ISP *does* have an ARP proxy). This, of course, fills up the
machines' ARP tables ridiculously (the entire Internet is on one big hub
as far as we can tell), and we see a lot of messages such as
arplookup 130.83.48.102 failed: could not allocate llinfo
arpresolve: can't allocate llinfo for 130.83.48.102rt
in the daily "kernel log messages" ; presumably, because the arp tables
fill up. Being able to have a gateway would alleviate the stress on the
arp tables too.
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?39DF7F6D.48AEE934>