Date: Wed, 03 Dec 2008 06:12:01 -0800 From: Julian Elischer <julian@elischer.org> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: freebsd-net@freebsd.org, Frank Behrens <frank@harz.behrens.de> Subject: Re: Problem with new source address selection Message-ID: <493693B1.3030306@elischer.org> In-Reply-To: <20081203104040.D80401@maildrop.int.zabbadoz.net> References: <200811271542.mARFgglB004902@post.behrens.de> <200811280653.mAS6r1P3014050@post.behrens.de> <20081203104040.D80401@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Bjoern A. Zeeb wrote:
> On Fri, 28 Nov 2008, Frank Behrens wrote:
>
> Hi,
>
>> Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net> wrote on 27 Nov 2008
>> 16:47:
>>>> Now I want to tunnel between my 192.168.90.0/24 and a foreign
>>>> 192.168.200.0/24. So I assigned 192.168.90.254/32 to lo2 and created
>>>> a static route.
>>>
>>> So if you don't mind to go out with a source address of 192.168.90.1
>>> instead of .254, what about this hack. What happens if you change the
>>> route to
>>> route change -net 192.168.200.0/24 192.168.90.2
>>> (assuming the .2 is not on your local machine).
>>
>> 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
>
>
>> 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.
>
>
> 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).
>
> Currently trying to discuss this with people.
can you assign a second FIB to handle this case?
>
> ------------------------------------------------------------------------
> Index: sys/netinet/in_pcb.c
> ===================================================================
> --- sys/netinet/in_pcb.c (revision 185571)
> +++ sys/netinet/in_pcb.c (working copy)
> @@ -696,6 +696,10 @@
> ia = ifatoia(ifa_ifwithnet(sintosa(&sain)));
>
> if (cred == NULL || !jailed(cred)) {
> +#if __FreeBSD_version < 800000
> + if (ia == NULL)
> + ia = (struct in_ifaddr *)sro.ro_rt->rt_ifa;
> +#endif
> if (ia == NULL) {
> error = ENETUNREACH;
> goto done;
> ------------------------------------------------------------------------
>
>
> /bz
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?493693B1.3030306>