In message <20050413171405.GA19330@antioche.lip6.fr>,
Manuel Bouyer writes:

>Hi,
>I have the following setup:
>                _______________                     _________
>--- public IP | NetBSD 3.0 box |10.1.1.1----10.1.1.2| Router|Internet-------
>                ---------------                     ---------
>
>That is, the NetBSD box has a public IP, on a public IP network, but it's
>not the network connecting it to the default router (its default route is
>10.1.1.2).
>This works mostly fine, exept that for outgoing connections from the NetBSD
>box, the source address is 10.1.1.1.
>Is there a way to force it to use the public IP for outgoing connections ?
>I tried playing with the -ifa modifier to route, without results.

Hi Manuel,

I'm not sure this is even workable.

You want outbound traffic to gos out the local 10.1.1.1 interface to
the box labelled "router", which forwards to the public Internet.
But what is the return path supposed to be?  Via the ``public IP'' on the
NetBSD box, or via the box labelled `router'?  More: is the router
using the same routable subnet as the ``public IP'', or is it a
disjoint subnet?

If disjoint, then most ISPs are going to drop your packets due to
ingress filtering (as far as they can see, your router is
IP-source-spoofing the ``public IP''). And even if your ISP doesn't do
ingress filtering, you won't be able to communicate with other
subscribers to the AS of your `public IP'': those hosts will will try
to reach your NetBSD host directly via the its left interface.

OTOH, if the addresses are on the same subnet -- which amounts to
saying that the left and right lines of your diagram are joined --
then I don't see why you would care.  Am I missing something?

For non-bound sockets, IP is going to pick whatever it thinks is the
first-listed address of the outbound interface. I'd expect that to be
the 10.1.1.1 address. But is that your only problem?

On your NetBSD machine, try binding a socket to a local address, then
initiate a connection to a distant host.  Does that work?  How about
connections to another host on another subnet of the `public IP' of
the NetBSD box?