[ previous ] [ next ] [ threads ]
 
 From:  Manuel Kasper <mk at neon1 dot net>
 To:  "J. James" <icewalker at hotpop dot com>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Proxy ARP (working, but not on production environment)
 Date:  Fri, 14 May 2004 22:57:38 +0200
On 14.05.2004 23:36 +0300, J. James wrote:

> But this brings the question whether or not you should also be able
> to use "real IP addresses" instead of proxy arping. Manuel: is
> there a reason why you couldn't have both possibilities?

As far as upstream routers are concerned, it makes no difference to
them at all. The result is the same in both cases: m0n0wall responds
to ARP queries for a given IP address and therefore receives packets
destined to that address and can then determine their fate. I don't
know what went wrong with proxy ARP in your case, but (assuming it
was set up properly and no old ARP information was cached) it would
have been no different with IP aliasing on the WAN interface.
Besides, proxy ARP isn't something that your ISP has to enable - they
don't even need to know that you're using it, because in fact their
router won't even be able to tell whether you use aliasing or proxy
ARP (as far as MAC address resolution is concerned).

The reason why there's no IP aliasing (anymore) is that it doesn't
scale well (what if you need to alias for a whole /24 subnet? You'd
have to bind 254 IP addresses to the WAN interface!) and that it's
not really needed if you're going to NAT or route the packets to some
other host anyway - handling the ARP queries in a userland daemon
(choparpd, as used in m0n0wall) is enough; the kernel doesn't need to
"impersonate" these IP addresses (as it does with aliasing). Besides,
if you have a real routed subnet (which any decent ISP should be able
to provide), there's no need for proxy ARP or IP aliasing anyway.

- Manuel