Date: Thu, 30 Jul 2009 22:36:26 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Julian Elischer <julian@elischer.org> Cc: Qing Li <qingli@freebsd.org>, "Li, Qing" <qing.li@bluecoat.com>, Matthias Andree <matthias.andree@gmx.de>, Stefan Bethke <stb@lassitu.de>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: recent change to ifconfig breaks OpenVPN? Message-ID: <20090730220658.M245@maildrop.int.zabbadoz.net> In-Reply-To: <4A721160.5080902@elischer.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><BEE762CA-4282-4BA8-B92B-AFC7AAE3CA9A@lassitu.de> <ABCF4747-24D4-4435-952B-EA85A2AE999F@lassitu.de> <B583FBF374231F4A89607B4D08578A4304E22D95@bcs-mail03.internal.cacheflow.com> <4A721160.5080902@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 Jul 2009, Julian Elischer wrote:
Hi,
some comments though it's late and I just got back from a UG meeting.
> note that he is using *ether* which seems odd. Since we are talking about
> tun. Is this the correct variable?
yes:
net.link.ether.inet.useloopback: 1
net.inet6.icmp6.nd6_useloopback: 1
(I guess historical accident).
Stefan Bethke <stb@lassitu.de> wrote:
> 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".
Exactly, that is the problem. So this is a ports issue.
> 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
The ifconfig error you can see in HEAD is, as pointed out before, from installing
the additional route for the local address to the local machine that the
command above already installs for the remote end. Changing
sysctl net.link.ether.inet.useloopback=0
and the error goes away, as the extra route is not installed by the
kernel and everything seems fine (to answer Qing).
I would say that this is bad but still works (even with the ioctl
error):
tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
inet 44.128.127.2 --> 44.128.127.2 netmask 0xffffff00
The problem is that seems bogus; It means that you reach the remote end
on the local address; so it's kind of
ifconfig lo0 44.128.127.2/32 alias
You will never reach the remote ptp end this way and that'll not be any
help with openvpn. I wonder what got the packets out in the past;
probably lax checking and some other magic.
Side-note: the same applies to a gif tunnel.
> 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
Yeah that is as great as we are or rather were.
So really, fix the openvpn scripts that assign the address to
interfaces to do something that would make sense from the ``man ip''
(not the literal command) point of view. Just that it's "working"
somewhere or used to work elswhere neither means that it was correct
nor made sense at any time before.
/bz
--
Bjoern A. Zeeb The greatest risk is not taking one.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090730220658.M245>