On Mon, 2005-07-11 at 12:06 -0400, chip wrote:
In the case of Proxy arp a host between the router and the actual host
you are wanting to talk with plays middle man and passes traffic back
and forth. The middleman host usually being a firewall of some sort.
Ooo... I meant to mention this earlier, but I got a bit distracted.
Proxy ARP is an especially good thing to bring up as a newbie topic
because it's got some incredibly handy uses. First and foremost in my
eyes is a form of interface hiding.
Okay, disclaimer, for "hiding" in the sense of keeping people from
knowing it's there, it's incredibly thin. A traceroute will typically
reveal that an extra machine is there with little trouble unless some
semi-risky things are done to up (or preserve) the TTL count between
hops. (Note: Changing or failing to reduce the Time To Live on a packet
is in general, a bad idea because it opens up the chance that a packet
might erroneously wind up being passed around indefinitely instead of
being dropped after travelling a max of 255 hops.)
Basically, if you've ever done a traceroute and seen private/reserved IP
addresses appear in the list, you're seeing proxy ARP in action. For
home networks, this can be used to one's advantage fairly well. Let's
say you've got a nailed up DSL line and a small number of IP addresses
(like a /29 or /30 netblock, or just 10 IPs). Typically you may have to
lose two out of your netblock--one for the broadcast address (all ones)
and one for the network address (all zeros), but that's kind of
irrelevant to the trick. (After reading this, some people may get the
idea that they can recover those as well. Don't do that. It will be
bad. Also don't try this if you have DHCP-allocated addresses, since
it's important that the router one hop up from you never change, unless
you like pain.)
Instead of assigning your precious publicly-routable internet IP
addresses to your firewall, stick a private network address on *both*
interfaces... say, 172.16.1.2 for the external interface and 172.16.1.1
for the internal interface (these both being part of the 172.16.0.0/12
IANA reserved netblock). The routing tables for the firewall will be
very easy to set up... The default (0.0.0.0) route goes on the
appropriate interface, and on the internal interface you'll want to
define a route for your happy little netblock (for example,
128.128.128.128/30 if you have a CIDR allocation, or static routes for
each of your IP addresses if you don't--there won't be many so it
shouldn't cause a performance issue) now things are all set for the IP
address layer and the skullduggery of ARP publishing takes place where
you tell your firewall to start *lying* about what IP addresses it's
responsible for. Using the arp command (or whatever utility you have
available in your little firmware-based store-bought firewall) you tell
it to publish on the *external* interface that it's responsible for all
of your ISP-given IP addresses, so that when your ISPs router does an
ARP query to find out where say, 128.128.128.129 is, your firewall's
external interface will pipe up and say "That's me!" and that router
will start handing over the packets as if it were talking to the correct
machine. Provided you didn't put in firewall rules to deny forwarding
for this, the packet will make it's way to the routing table of your
firewall, and the routing table say "Oh wait, that's not me" and then it
will do an ARP query on the interface appropriate to the network it
thinks the packet is for (generally not all interfaces, although some
machines will--this is imprecise but still correct behaviour) get an
answer from your machine on the inside that *is* configured for that IP
address, and forward it right on. Now for returning packets, the
internal rule is even easier. You just need use the arp command so that
your firewall will respond on the internal interface as if it were the
IP address that your ISP has told you to use as your default router.
Your internal machines need never be told any different--as far as they
know, they're on the same network segment as the ISP's router.
Now that it's been explained in plain language, I'll recap a little more
technically with some examples for Linux (which I may or may not have
entirely correct, consult your man pages if these commands give you
errors) and hopefully everyone will catch on.
The default router your ISP has told you to use: 128.128.1.1
Your assigned IP addresses: 128.128.24.1, 128.128.24.2, and so on...
To set your internal (eth0) interface so that it performs ARP responses
on behalf of the upstream router you use:
arp -i eth0 -s 128.128.1.1 00:0C:DE:BE:DE:BE pub
Note that the 00:0C:DE:BE:DE:BE is supposed to be the MAC address of
your internal interface, which you can see with the ifconfig command.
With some OSes you don't even have to specify that. (oh, and about the
man pages, at this level "hostname" in the ARP man page is basically
referring to an IP address, not an ascii hostname as some might assume
and be confused by). With this in place, any time an ARP query to find
128.128.1.1 is seen on eth0, the kernel will reply that the IP address
belongs to it.
To set your external interface (eth1) so that it performs proxy ARP for
your internal network addresses, you'd use a series of commands like
this (some operating systems don't even require this, they assume it
based on the fact that they're a router and they know where the route
goes, but it doesn't hurt to be explicit):
arp -i eth1 -s 128.128.24.1 00:08:DE:AD:BE:EF pub
arp -i eth1 -s 128.128.24.2 00:08:DE:AD:BE:EF pub
arp -i eth1 -s 128.128.24.3 00:08:DE:AD:BE:EF pub
...and so on.
Again, 00:08:DE:AD:BE:EF is supposed to be the MAC (ethernet) address
for the eth1 interface. The "pub" part makes it a permanent addition to
the ARP cache so it won't expire. So now when the upstream router asks
"Where's 128.128.24.2?" your firewall will answer on it's external
interface, and be able to get the packets.
Some last tidbits: If you don't fully understand IP routing yet, don't
try this--the added complexity will drive you mad. You *can* with the
addition of the proper route on your internal hosts *still* reach the
internal interface of your firewall because it's on the same segment as
those internal hosts (and packets going to the default route will get
there anyway). And last but not least, if you are using Linux and you
happen to have a problem where the internal interface is doing ARP
replies for the IP address of the external interface, go here
(http://www.ssi.bg/~ja/#hidden) to get a patch that will allow you to
make the kernel only respond to queries for the IP address of that
particular interface. Get used to using the -e flag for tcpdump when
trying to debug this sort of thing.
signature.asc
Description: This is a digitally signed message part
