recent change to ifconfig breaks OpenVPN?
Stefan Bethke
has problems ifconfig'ing a tun interface.
With sources from about one week ago, this is working:
Jul 29 03:07:15 diesel openvpn_zs64[14785]: /sbin/ifconfig tun1
44.128.127.2 44.128.127.2 netmask 255.255.255.0 mtu 1500 up
Jul 29 03:07:15 diesel openvpn_zs64[14785]: /sbin/route add -net
44.128.127.0 44.128.127.2 255.255.255.0
Jul 29 03:07:15 diesel openvpn_zs64[14785]: /sbin/route add -net
44.128.64.0 44.128.127.1 255.255.192.0
Now, the same sequence fails:
Jul 29 17:31:41 diesel openvpn_zs64[1855]: /sbin/ifconfig tun1
44.128.127.2 44.128.127.2 netmask 255.255.255.0 mtu 1500 up
Jul 29 17:31:41 diesel openvpn_zs64[1855]: FreeBSD ifconfig failed:
external program exited with error status: 1
Trying the same command manually gets me:
/sbin/ifconfig tun1 44.128.127.2 44.128.127.2 netmask 255.255.255.0
mtu 1500 up
ifconfig: ioctl (SIOCAIFADDR): File exists
even though no address was assigned before.
Another OpenVPN instance using tap continues to work.
Stefan
--
Stefan Bethke <s...@lassitu.de> Fon +49 151 14070811
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Julian Elischer
> I just updated this afternoon (r195941), and after rebooting, OpenVPN
> has problems ifconfig'ing a tun interface.
>
> With sources from about one week ago, this is working:
> Jul 29 03:07:15 diesel openvpn_zs64[14785]: /sbin/ifconfig tun1
> 44.128.127.2 44.128.127.2 netmask 255.255.255.0 mtu 1500 up
> Jul 29 03:07:15 diesel openvpn_zs64[14785]: /sbin/route add -net
> 44.128.127.0 44.128.127.2 255.255.255.0
> Jul 29 03:07:15 diesel openvpn_zs64[14785]: /sbin/route add -net
> 44.128.64.0 44.128.127.1 255.255.192.0
>
> Now, the same sequence fails:
> Jul 29 17:31:41 diesel openvpn_zs64[1855]: /sbin/ifconfig tun1
> 44.128.127.2 44.128.127.2 netmask 255.255.255.0 mtu 1500 up
> Jul 29 17:31:41 diesel openvpn_zs64[1855]: FreeBSD ifconfig failed:
> external program exited with error status: 1
>
> Trying the same command manually gets me:
> /sbin/ifconfig tun1 44.128.127.2 44.128.127.2 netmask 255.255.255.0 mtu
^^^^^^^^^^^^^^^^^^^^^^^^^
have you tried it without using the same address on both ends?
> 1500 up
> ifconfig: ioctl (SIOCAIFADDR): File exists
>
> even though no address was assigned before.
>
> Another OpenVPN instance using tap continues to work.
>
>
> Stefan
>
_______________________________________________
Stefan Bethke
> Stefan Bethke wrote:
>> I just updated this afternoon (r195941), and after rebooting,
>> OpenVPN has problems ifconfig'ing a tun interface.
>> With sources from about one week ago, this is working:
>> Jul 29 03:07:15 diesel openvpn_zs64[14785]: /sbin/ifconfig tun1
>> 44.128.127.2 44.128.127.2 netmask 255.255.255.0 mtu 1500 up
>> Jul 29 03:07:15 diesel openvpn_zs64[14785]: /sbin/route add -net
>> 44.128.127.0 44.128.127.2 255.255.255.0
>> Jul 29 03:07:15 diesel openvpn_zs64[14785]: /sbin/route add -net
>> 44.128.64.0 44.128.127.1 255.255.192.0
>> Now, the same sequence fails:
>> Jul 29 17:31:41 diesel openvpn_zs64[1855]: /sbin/ifconfig tun1
>> 44.128.127.2 44.128.127.2 netmask 255.255.255.0 mtu 1500 up
>> Jul 29 17:31:41 diesel openvpn_zs64[1855]: FreeBSD ifconfig failed:
>> external program exited with error status: 1
>> Trying the same command manually gets me:
>> /sbin/ifconfig tun1 44.128.127.2 44.128.127.2 netmask 255.255.255.0
>> mtu
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> have you tried it without using the same address on both ends?
Sure, I changed to a custom up script that configures a different
address for the other end. The question is: is this an intended
change, and does OpenVPN need to be changed?
Note that the addresses OpenVPN passed to ifconfig are determined
automatically based on various config parameters (both on the client
and on the server), so it's not a simple configuration change.
It used to be that ifconfig would assign the local address to the p2p
interface, and would add a route to the VPN block via that one
address. This is from a 7-stable machine connected to the same server:
$ ifconfig tun0
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
inet 44.128.127.14 --> 44.128.127.14 netmask 0xffffff00
Opened by PID 760
$ netstat -rnfinet
...
44.128.127.0/24 44.128.127.14 UGS 2 499 tun0
44.128.127.14 44.128.127.14 UH 1 0 tun0
...
I'm guessing that adding that host route is not working anymore, and
that's why ifconfig is failing.
The end result necessary for an OpenVPN setup like mine ("topology
subnet") is a tun interface with the local address assigned by the
server configuration, and a route to the server-configured subnet
going out via the tun interface. The remote address on the tun
interface does not actually matter, and no host route is necessary.
I have a feeling OpenVPN needs to be changed wrt computing the proper
ifconfig parameters.
Stefan
--
Stefan Bethke <s...@lassitu.de> Fon +49 151 14070811
Matthias Andree
> Am 29.07.2009 um 20:12 schrieb Julian Elischer:
>
>> Stefan Bethke wrote:
>>> I just updated this afternoon (r195941), and after rebooting, OpenVPN
>>> has problems ifconfig'ing a tun interface.
>>> With sources from about one week ago, this is working:
>>> Jul 29 03:07:15 diesel openvpn_zs64[14785]: /sbin/ifconfig tun1
>>> 44.128.127.2 44.128.127.2 netmask 255.255.255.0 mtu 1500 up
>>> Jul 29 03:07:15 diesel openvpn_zs64[14785]: /sbin/route add -net
>>> 44.128.127.0 44.128.127.2 255.255.255.0
>>> Jul 29 03:07:15 diesel openvpn_zs64[14785]: /sbin/route add -net
>>> 44.128.64.0 44.128.127.1 255.255.192.0
>>> Now, the same sequence fails:
>>> Jul 29 17:31:41 diesel openvpn_zs64[1855]: /sbin/ifconfig tun1
>>> 44.128.127.2 44.128.127.2 netmask 255.255.255.0 mtu 1500 up
>>> Jul 29 17:31:41 diesel openvpn_zs64[1855]: FreeBSD ifconfig failed:
>>> external program exited with error status: 1
>>> Trying the same command manually gets me:
>>> /sbin/ifconfig tun1 44.128.127.2 44.128.127.2 netmask 255.255.255.0 mtu
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> have you tried it without using the same address on both ends?
>
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?
Thanks & best regards
Matthias
Stefan Bethke
> 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 <s...@lassitu.de> Fon +49 151 14070811
Matthias Andree
there is an OpenVPN regression, apparently affecting 2.1 on FreeBSD-8, and
caused by OpenVPN configuring the local address on a P2P interface for the
local AND ALSO the remote address.
See
http://lists.freebsd.org/pipermail/freebsd-current/2009-July/010032.html
and followups for details.
Am 30.07.2009, 08:40 Uhr, schrieb Stefan Bethke <s...@lassitu.de>:
> 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,
Which version of OpenVPN are you using?
It might seem that this is a FreeBSD regression, as OpenVPN assumes this
about --topology subnet, so that the using of the local address as remote
is intentional.
(This is from the current OpenVPN 2.1-RC manpage):
subnet -- Use a subnet rather than a point-to-point
topology by
configuring the tun interface with a local IP address and
subnet
mask, similar to the topology used in --dev tap and
ethernet
bridging mode. This mode allocates a single IP address per
con-
necting client and works on Windows as well. Only
available
when server and clients are OpenVPN 2.1 or higher, or
OpenVPN
2.0.x which has been manually patched with the --topology
direc-
tive code. When used on Windows, requires version 8.2 or
higher
of the TAP-Win32 driver. When used on *nix, requires that
the
tun driver supports an ifconfig(8) command which sets a
subnet
instead of a remote endpoint IP address.
I see this in the ChangeLog:
2006.04.05 -- Version 2.1-beta12
...
* "topology subnet" fix for FreeBSD (Benoit Bourdin).
...
And it appears that exactly this patch may be the culprit. This is from
the OpenVPN 2.1 source repository:
------------------------------------------------------------------------
r986 | james | 2006-04-05 08:28:19 +0200 (Wed, 05 Apr 2006) | 2 lines
Changed paths:
M /branches/BETA21/openvpn/tun.c
"topology subnet" fix for FreeBSD (Benoit Bourdin).
------------------------------------------------------------------------
Index: tun.c
===================================================================
--- tun.c (Revision 985)
+++ tun.c (Revision 986)
@@ -795,19 +795,42 @@
ifconfig_remote_netmask,
tun_mtu
);
- else
- openvpn_snprintf (command_line, sizeof (command_line),
+ else {
+ if (tt->topology == TOP_SUBNET)
+ openvpn_snprintf (command_line, sizeof (command_line),
+ IFCONFIG_PATH " %s %s %s netmask %s mtu %d
up",
+ actual,
+ ifconfig_local,
+ ifconfig_local,
+ ifconfig_remote_netmask,
+ tun_mtu
+ );
+ else
+ openvpn_snprintf (command_line, sizeof (command_line),
IFCONFIG_PATH " %s %s netmask %s mtu %d up",
actual,
ifconfig_local,
ifconfig_remote_netmask,
tun_mtu
);
+ }
msg (M_INFO, "%s", command_line);
system_check (command_line, es, S_FATAL, "FreeBSD ifconfig failed");
tt->did_ifconfig = true;
+ /* Add a network route for the local tun interface */
+ if (!tun && tt->topology == TOP_SUBNET)
+ {
+ struct route r;
+ CLEAR (r);
+ r.defined = true;
+ r.network = tt->local & tt->remote_netmask;
+ r.netmask = tt->remote_netmask;
+ r.gateway = tt->local;
+ add_route (&r, tt, 0, es);
+ }
+
#elif defined (WIN32)
{
/*
--
Matthias Andree
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
Li, Qing
-- Qing
> To unsubscribe, send any mail to "freebsd-current-
> unsub...@freebsd.org"
Julian Elischer
> I will look into it.
>
> -- Qing
>
>
>> -----Original Message-----
>> From: owner-free...@freebsd.org [mailto:owner-freebsd-
>> cur...@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 01:46 schrieb Matthias Andree:
>>>
>>>>
>>>> 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?
>>> 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.
>> Stefan
>>
>> --
>> Stefan Bethke <s...@lassitu.de> Fon +49 151 14070811
>>
>>
>>
>>
>> _______________________________________________
>> freebsd...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-
>> unsub...@freebsd.org"
Julian Elischer
the previous behaviour was wrong.
It is a configuration error to have the same address on two different
machines, (except in the special case of fail-over stuff, which has
special case code to cope with it.)
Of course you don't have to assign ANY address.
ifconfig tun0 create
route add default -iface tun0
will work just fine.
but having the same address on both ends is a problem. For example
sshd will listen to that address on both machines,
so if you ssh to that address, which machine you get depends on which
machine your packet reaches first.
The problem here is that Qingli was trying to make it so that if you
did an 'ssh x.x.x.x' where x.x.x.x was your local address on the p2p
interface, that it worked instead of sending the packet out.
This means puting in a route to localhost for the local side address.
Unfortunatly, if the local address and remote address are the same,
then the route already exists so an error occurs.
One might say that it is up to IP to know before hand that it is a
local address and not bother routing it in the first place.
I'm not sure whatthe behaviour in this case was in 7.x and don't have
one to try..
it'd be instructive to see the result of:
ifconfig tun0 create
ifconfig tun0 1.1.1.1 2.2.2.2
route get 1.1.1.1
ssh 1.1.1.1
netstat -rn
on a 7.x and 6.x (and earlier?) machine.
>
>
> Stefan
Li, Qing
> 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.
>
In 7.x and prior releases, the local-ip of the PPP links
(e.g. tun, gif, gre) is not reachable within that system. I don't
know if that really make sense.
The Host Requirements RFC-1122, Section 3.3.4 on Local Multihoming seems
to suggest the local-ip of a PPP link is not irrelevant as was treated
by
the implementation.
In r195914, I added a loopback route for the local-ip of the local end
of a PPP link to make the local-ip reachable within the system.
Since a host route is installed for the remote end, the installation
of the loopback route for the local-ip (that is the same IP as the
remote end)
fails. As Julian pointed out, the configuration from OpenVPN seems
erroneous.
At this point I don't believe there is anything I need to fix but
comments are welcomed.
>
> Setting net.link.ether.inet.useloopback=0 does not restore the
> previous behavior.
>
I also verified setting (useloopback=0) * does * restore to the
previous
behavior.
-- Qing
Julian Elischer
note that he is using *ether* which seems odd. Since we are talking
about tun. Is this the correct variable?
Bjoern A. Zeeb
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 <s...@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.
Matthias Andree
<bzeeb...@lists.zabbadoz.net>:
> 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.
It's actually in the C code where it was advertised as FreeBSD fix.
OpenVPN runs in 'topology subnet' mode here, which is documented as
follows:
Use a subnet rather than a point-to-point topology by
configuring the tun interface with a local IP address and subnet
mask, similar to the topology used in --dev tap and ethernet
bridging mode. This mode allocates a single IP address per con-
necting client [... MS-Windows stuff here ...]
When used on *nix, requires that the
tun driver supports an ifconfig(8) command which sets a subnet
instead of a remote endpoint IP address.
I wonder if TUNSIFMODE (see tun(4)) is somehow needed and if so, already
done, and how the proper ifconfig call would look like in this case.
Stefan already uttered some ideas in that direction.
I haven't had much time to investigate yet.
--
Matthias Andree
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Stefan Bethke
> Setting net.link.ether.inet.useloopback=0 does not restore the
> previous behavior.
Li, Qing wrote:
>
> I also verified setting (useloopback=0) * does * restore to the
> previous behavior.
I apologize. I tested again, and setting
net.link.ether.inet.useloopback=0 does indeed restore previous
behavior, and is a valid workaround for running OpenVPN unchanged.
Matthias, you might want to have a notice to that effect added to the
port for the time being.
I agree that assigning the same address to both the local and the
remote address of a p2p link is not really sensible, and will try to
come up with a patch to OpenVPN.
Thanks for the clarification and insight,
Stefan
--
Stefan Bethke <s...@lassitu.de> Fon +49 151 14070811