Re: recent change to ifconfig breaks OpenVPN?

Li, Qing wrote:
> I will look into it.
> 
> -- Qing
> 
> 
>> -----Original Message-----
>> From: owner-freebsd-current_at_freebsd.org [mailto:owner-freebsd-
>> current_at_freebsd.org] On Behalf Of Stefan Bethke
>> Sent: Thursday, July 30, 2009 9:46 AM
>> To: Qing Li; Bjoern A. Zeeb
>> Cc: Matthias Andree; FreeBSD Current
>> Subject: Re: recent change to ifconfig breaks OpenVPN?
>>
>> 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.

It seems that it doesn't like if both ends of a p2p
have the same address.
This is a numbering scheme sometimes used in routers,
but it has funny side effects on hosts. For example both hosts would 
respond to ssh 'local_ip'. I'm in two minds as to whether one would 
want to allow this.

>>>
>>> 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
>>
>>
>>
>>
>> _______________________________________________
>> freebsd-current_at_freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-
>> unsubscribe_at_freebsd.org"
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"