--Az4VpBrmI9+OyhK/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Feb 17, 2005 at 03:31:34AM -0500, der Mouse wrote:
> > 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?)
>=20
> 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.
So, yes, that's the inverse equivalent of the case I had in mind, but
just as problematic: arp doesn't add them to the interface where you
need them.
> Unfortunately it doesn't work to remove them, which I'd need to do
> to switch the guest machine's MAC to another one
I'm not sure why you have trouble changing any of those if the guest
host changes, since in that case it'd be the fake 10.0.0.3 arp address
you want to change, and that's on-subnet. All the proxy entries use
your own mac addresses. Even so, the feature is incomplete if
deletion doesn't work, but it's a useful feature for arp to have.
does arp -f or ifconfig qe2 0.0.0.0 down clear them?
> 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). =20
Yup, but you need to take care. Note that neither a switch nor
bridge(4) is protection against sniffing without additional
configuration; see ettercap and other arp poisoning sniffing/mitm
techniques. You want BRIDGE_IPF there and some topology enforcement
rules.
> (If you can think of any better way of doing this *with 1.4T*,
> I'm all ears.)
I use ipnat for a similar case to what you do with srt; certain
outbound connections from a machine with a ISP-provided WAN address
are instead presented coming from some of my own internal addresses
routed via that machine (so I can give them my own rDNS entries).
The other part of srt (the destination route), I'd do with a normal
host route, or an ipf "pass ... to qe2:10.0.0.3 .." depending on other
circumstances.
I'm not sure why you want to give the guest machine an address from
the internal address range, giving them a separate subnet with rfc1918
addresses, and NAT to the 14 address, seems the standard
solution. Let's say you have a protocol which doesn't survive NAT.
The only tricky part is adding the proxy arp entries to qe2 in the
loop without the if argument. Another option there would be a
userspace bpf daemon to send the arp replies, like ettercap or LaBrea
does (but much simpler, of course). There's net/arpd in pkgsrc, which
has a promising name and an utterly confusing DESCR. Plus any packets
initiated from the house lan will likely seed the guest's arp cache
anyway.
Still, I've wished arp would take an interface argument in the past,
having tripped over this kind of thing before.
--
Dan.
--Az4VpBrmI9+OyhK/
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)
iD8DBQFCFJevEAVxvV4N66cRAqpUAKCeJk1RFZMngB6/asDQqj2L8DrZNQCg5G4r
kPBbxGMNb8vy3ZQoKeciJno=
=poj9
-----END PGP SIGNATURE-----
--Az4VpBrmI9+OyhK/--