--0/kgSOzhNoDC5T3a
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Nov 07, 2004 at 07:45:15PM +0100, Tom Ivar Helbekkmo wrote:
> manu@netbsd.org (Emmanuel Dreyfus) writes:
>=20
> > Beside having the same local address selected for any protocol, I
> > really need to be able to set a "prefered" local address.
>=20
> Hear! Hear!  I've missed this many times.

Likewise.

> > The latter sounds the most general, so it might be the best way to go.
>=20
> Absolutely.  This is exactly the thing I've needed, in situations
> where I've ended up separately configuring it for each application
> that *could* specify its local address, and just living with the fact
> that those that couldn't, ended up with the wrong one.
>=20
> The per route preferred local address covers the per interface one,
> and is a more general, and more elegant, solution.  I say do it.  :-)
>=20
> Oh, and it needs to be possible to specify a local address that isn't
> actually on the outgoing interface, but is a local address on another
> interface, and is thus still reachable for the return traffic.  This
> would be used to route traffic out through more than one interface,
> while always having it originate at the system's primary address.

I've been doing this sort of thing with ipnat, for example where I
have a gateway machine with routed addresses behind it, and
link-addresses I don't want used as sources for outbound connections
originating on the gateway. =20

Not exactly the Right Way to do it, but it's at least easy to be
explicit about exactly what should happen.  It also allows you to
specify different source addresses per outgoing port, which a routing
table entry wouldn't[*]. In this example, the machine has a number of
service-related alias addresses on the internal interface (DNS, SMTP,
etc), and i want its outbound connections for those to originate from
the relevant addresses.

--
Dan.

* I'd really like to see policy-routing capabilities to have routes
  selected by a number of other criteria than currently, but there are
  a number of ways it might be done and it's really a different,
  larger discussion about generalised packet/session classifiers.

--0/kgSOzhNoDC5T3a
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iD8DBQFBjoZIEAVxvV4N66cRAguMAKDCzZA5mXq6JMqK/SpUkD/1YBGcMACglyyS
KL+FLwrqGzL30lO6Rlipj3w=
=jfNG
-----END PGP SIGNATURE-----

--0/kgSOzhNoDC5T3a--