Date: Thu, 30 Jul 2009 08:40:19 +0200 From: Stefan Bethke <stb@lassitu.de> To: Matthias Andree <matthias.andree@gmx.de> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: recent change to ifconfig breaks OpenVPN? Message-ID: <BEE762CA-4282-4BA8-B92B-AFC7AAE3CA9A@lassitu.de> In-Reply-To: <op.uxusbswp1e62zd@merlin.emma.line.org> References: <B4AA014B-2444-40AA-A3A3-417E4B89DF90@lassitu.de> <4A709126.5050102@elischer.org> <3A1518B9-2C8C-4F05-9195-82C6017E4902@lassitu.de> <op.uxusbswp1e62zd@merlin.emma.line.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Stefan
p.s. log output wrt ifconfig:
FreeBSD (working up to last week, continues to work in -stable):
/sbin/ifconfig tun1 44.128.127.2 44.128.127.2 netmask 255.255.255.0
mtu 1500 up
Linux:
/sbin/ifconfig tun4 44.128.127.15 netmask 255.255.255.0 mtu 1500
broadcast 44.128.127.255
It is interesting to note that tun4 on the Linux box has the same
local and remote address:
/sbin/ifconfig tun4
tun4 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:44.128.127.15 P-t-P:44.128.127.15 Mask:
255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
--
Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BEE762CA-4282-4BA8-B92B-AFC7AAE3CA9A>