recent change to ifconfig breaks OpenVPN?

Stefan Bethke stb at lassitu.de
Thu Jul 30 16:46:07 UTC 2009


Am 30.07.2009 um 08:40 schrieb Stefan Bethke:

> Am 30.07.2009 um 01:46 schrieb Matthias Andree:
>
>> Hi everybody,
>>
>> If that is the case, then we should go quickly to either make it go  
>> into 8-CURRENT's ports or OpenVPN 2.1, or both.
>>
>> I'm not sure I have sufficient context or time to read up to  
>> determine my own role here (I haven't been following -current for  
>> lack of time); can someone summarize the issue for me?
>
> I can try to summarize; I don't think I'll have time to come up with  
> a patch this weekend.
>
> The problem appears to be that OpenVPN invokes ifconfig with  
> incorrect (but previously working) parameters, namely "ifconfig tun0  
> local_ip local_ip" instead of "ifconfig tun0 local_ip remote_ip".   
> The problem does not appear to be the SIOCAIFADDR but the RT_ADD  
> that ifconfig does.  When I drafted a replacement OpenVPN --up  
> script yesterday, I also noticed that the parameters passed to the  
> script are wrong (netmask instead of remote ip), and environment  
> variables are partially not set (ifconfig_remote is empty).
>
> This issue appears to affect tun-mode connections; tap-mode  
> connections appear to continue to work.
>
> I'm not sure if that is a more general problem with OpenVPN (at  
> least in --topology subnet mode), or a specific problem in the  
> FreeBSD-specific code.  I just looked at a Linux box connected to  
> the same OpenVPN server, and their ifconfig invocation looks  
> different from ours, so the FreeBSD-specific code at least plays  
> some role.
>
> I'd still like to know whether the change to the routing code is  
> intentional or a regression.

I did at least have time to figure out the commit that changed it:  
195914

> Author: qingli
> Date: Mon Jul 27 17:08:06 2009
> New Revision: 195914
> URL: http://svn.freebsd.org/changeset/base/195914
>
> Log:
>  This patch does the following:
>
>      - Allow loopback route to be installed for address assigned to
>        interface of IFF_POINTOPOINT type.
>      - Install loopback route for an IPv4 interface addreess when the
>        "useloopback" sysctl variable is enabled. Similarly, install
>        loopback route for an IPv6 interface address when the sysctl  
> variable
>        "nd6_useloopback" is enabled. Deleting loopback routes for  
> interface
>        addresses is unconditional in case these sysctl variables were
>        disabled after an interface address has been assigned.


Setting net.link.ether.inet.useloopback=0 does not restore the  
previous behavior.


Stefan

-- 
Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811






More information about the freebsd-current mailing list