Stefan Bethke wrote: > 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. 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 >Received on Thu Jul 30 2009 - 15:46:52 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:53 UTC