>> It means rebooting the gateway to change almost anything about it (I
>> had to hack on various bits of the arp support to make it work at
>> all, and I can't take down some of the things once they're set up).
> I'm not sure why this should have been necessary, what was the
> behaviour you had to change?  (or was the fake gateway address you
> added not part of the subnet?)

I'm not entirely certain any longer; I think that the hard part was
dealing with arp entries not on the interface the code would pick by
default.  I added an optional interface specifier to arp(8) to override
the automatic choice of interface; see below.

Here's the basic configuration.  My house gateway, stone, has four
interfaces (well, five, but one of them is going unused): le0 (house
routable subnet), qe0 (DSL line), qe1 (house non-routable subnet), and
qe2 (used for the hackery in question).  The point of the hackery is
that I want to be able to have someone bring over a laptop and plug it
in to my net, while not allowing it to snoop traffic on the house LAN
in case it's 0wn3d.  (I think the chance of this is small, or I
wouldn't be offering the connectivity in the first place, but I'm
paranoid about such things, a believer in belt-and-suspenders.)

le0 is configured to 216.46.5.9/28.  qe0 is configured to
216.46.14.122/30.  qe1 is configured to 10.0.1.1/24.

Now, given this, I am faced with a problem.  I want to connect a
"guest" machine as 216.46.5.14 (or any other address on the routable
subnet, but that's the one I use).  But since my house network is a hub
rather than a switch, to achieve the non-sniffing goal, I want to
connect via stone's qe2.  Here's how I do that.  (Line numbers in the
left margin are added for purposes of this mail.)

 1 ifconfig qe2 10.0.0.1/29
 2 arp -d 10.0.0.3
 3 # This MAC address is that of the `guest' machine.
 4 arp -s 10.0.0.3 0:3:93:59:07:d6 if qe2
 5 srtconfig srt2 add 0.0.0.0 /0 qe2 10.0.0.3
 6 ifconfig srt2 216.46.5.9 10.0.0.253 netmask 0xffffffff up
 7 route add -host 216.46.5.14 10.0.0.253
 8 # This MAC address is that of stone's le0
 9 arp -s 216.46.5.14 08:00:20:0d:5b:8c pub proxy if le0
10 for h in 1 2 3 4 5 6 7 8 9 10 11 12 13
11 do
12	# This MAC address is that of stone's qe2
13 	arp -s 216.46.5.$h 08:00:20:0d:5b:8c pub proxy if qe2
14 done

Now, traffic from the world, or from the house non-routed subnet, to
216.46.5.14 hits stone and the route added at line 7 directs it to be
sent on srt2, with 10.0.0.253 as the next-hop address.  srt2's
configuration (line 5) redirects all traffic to qe2 with 10.0.0.3 as
the next-hop address (see below for why not simply route it to
10.0.0.3).  Because of the permanent ARP entry added by line 4, no ARP
request will be done and the packet will be emitted out qe2 addressed
to 0:3:93:59:07:d6, which is the Right Thing.  Traffic from the house
routed subnet will ARP; because of the proxy entry added by line 9,
this ARP will be answered by stone with its own MAC address and stone
will then receive the packet and treat it as sketched above.  Traffic
from the guest machine will ARP, for the target machine's address if
it's in the house routed subnet or for stone's 216.46.5.9 address if
not.  The proxy entries added by the loop in lines 10 through 14 ensure
that such arps will be answered with stone's own address, so it will
get the packet and route it appropriately.

The reason for using srt2 at all rather than just routing 216.46.5.14
via 10.0.0.3 is that if I did that, then connections originating on
stone to the guest machine would be coming from 10.0.0.1, since that's
stone's address on qe2.  I want them to come from 216.46.5.9 instead.
Since the route points out srt2, it uses srt2's local address, which is
(line 6) 216.46.5.9.  (srt interfaces are point-to-point.)

I needed to add the "if" specifier to arp to ensure that the various
proxy ARP entries got added on the correct interfaces.  Unfortunately
it doesn't work to remove them, which I'd need to do to switch the
guest machine's MAC to another one; as I recall, I looked at fixing
that and it looked like more work than just rebooting stone on those
few occasions when I want to connect up a different guest machine.

No doubt the original goal could be achieved in other ways, especially
with more recent NetBSD (setting up a bridge between le0 and qe2, for
example, looks like a good start).  I'm trying to explain, not justify,
here.  (If you can think of any better way of doing this *with 1.4T*,
I'm all ears.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B