Problem with new source address selection

[Frank Behrens]

Bjoern A. Zeeb <bzeeb-lists at lists.zabbadoz.net> wrote on 3 Dec 2008 11:03:
> On Fri, 28 Nov 2008, Frank Behrens wrote:
> > That works for the router, but for incoming packets on the internal
> > interface (from -net 192.168.90.0/24) the machine will send an ICMP
> > redirect to new router 192.168.90.2. Of course that is a black hole.
> > When I use the route to own interface address
> > (route change -net 192.168.200.0/24 192.168.90.1) it works, but also
> > for every incoming packet an ICMP redirect is sent. So that solution
> > is a workaround for short time only.
> 
> You can disable icmp redircts entirely but not sure if soemthing else
> would stop working in your network topology then.
> 
> sysctl net.inet.ip.redirect

This is the workaround I made in the meantime. I believe icmp 
redirects are for a working network not necessary, they are only an 
optimization.

> > Does anybody have a better solution for source address selection? Am
> > I the only one with an IPSEC tunnel?
> 
> The best solution actually is to teach your application to bind for
> this connection I guess instead of relying on any hack.

Hm, is this so easy? I thought address selection for outgoing 
connections is made by the OS? One of my test cases is bind/named. I 
don't know how to configure _multiple_ bind addresses for outgoing 
connections dependent from destination network.

As I mentioned earlier I believe the main problem is IPSEC itself, 
where we don't have an interface for tunneled connections. So I made 
a workaround with a dummy loopback device. So I have a question to 
the network specialists: Is there no other solution? Am I the only 
stupid man, who wants to tunnel a subnet with private address range 
via IPSEC?

> When it comes to the source address selection I am tempted to answer
> with: I am willing to still allow this in 7 to not break production
> setups but I am inclined to not change HEAD and keep the behavior
> dropped there. See patch below, which basically is what you had with
> the version check and the if (ia == NULL) check to not blindly overwrite
> if we had found anything closer (untested).

Thanks, I will try this.

Regards,
   Frank

-- 
Frank Behrens, Osterwieck, Germany
PGP-key 0x5B7C47ED on public servers available.