Problem with new source address selection (was Anyone interested in jail patches?)

[Frank Behrens]

Bjoern A. Zeeb <bzeeb-lists at lists.zabbadoz.net> wrote on 26 Nov 2008 23:56:
> If you are interested in a new set of jail patches... anyone?;-)

Yes, but about jail specific things I'll write later, in another mail 
and on another list.

> 2b) for RELENG_7:
>     http://people.freebsd.org/~bz/bz_jail7-20081126-02-at153644.diff

With this patch I received a new source selection implementation, I 
believe the same as announced for HEAD. Here I found a problem.

One of my machines tunnels a private subnet via IPSEC (esp/tunnel). 
Lets assume my private subnet is 192.168.90.0/24 and the "foreign" 
subnet is 192.168.200.0/24. When I send packets via this tunnel I 
must ensure the right source address, because the machine has several 
interfaces. (BTW: this is so easy with openvpn and real routing, but 
sometimes other people decide..) An easy solution was for me 
ifconfig lo2 inet 192.168.90.254/32
route add -net 192.168.200.0/24 -iface lo2 
The route is a "dummy" route only, because the IPSEC SPD determines 
the packet flow.  

This worked well in the past, but not with your patch. On connect(2) 
call for the tunneled subnet I receive always "Network unreachable".
The following _wild hack_(tm) solves the problem _for me_, it is only 
to show the problem to you:

--- sys/netinet/in_pcb.c.orig   2008-11-27 14:57:25.887082927 +0100
+++ sys/netinet/in_pcb.c        2008-11-27 14:29:28.918257601 +0100
@@ -697,6 +697,9 @@ in_pcbladdr(struct inpcb *inp, struct in
                        ia = ifatoia(ifa_ifwithnet(sintosa(&sain)));

                if (cred == NULL || !jailed(cred)) {
+// FB2008-11-27
+                       ia = (struct in_ifaddr *)sro.ro_rt->rt_ifa;
+// FB
                        if (ia == NULL) {
                                error = ENETUNREACH;
                                goto done;

Can you provide a patch to solve the connect problem?
Is there a better solution to setup source address selection for 
IPSEC tunnels?

Regards,
   Frank

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