Date: Thu, 27 Nov 2008 14:53:58 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Frank Behrens <frank@harz.behrens.de> Cc: freebsd-net@freebsd.org Subject: Re: Problem with new source address selection (was Anyone interested in jail patches?) Message-ID: <20081127143300.M61259@maildrop.int.zabbadoz.net> In-Reply-To: <200811271425.mAREPSwm004057@post.behrens.de> References: <200811271425.mAREPSwm004057@post.behrens.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Nov 2008, Frank Behrens wrote: >> 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. HEAD has had it since beginning of October and older jail patches also had it for a while now. > 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. Yes I know that hack though I never actually used it with a loopback as the loopback case is *uhm* gross. You know you are telling the kernel to actually send the packets to yourself which so far has just worked more or less out of luck in my eyes. So is your 192.168.90.0/24 on any other interface but the lo2? Is it the only network on that interface or are there aliases? > 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: >From the code down I take it that the connect(2) call happens outside any jail and not within a jail, right? > --- 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? Let me answer those later; in case you cannot reveal your network setup in public; contact me offlist. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081127143300.M61259>