Hi, I'm forwarding this "as-is", as I do not have enough understanding of autoconf to say whether this is necessary, or "the right fix" - but anyway, I've been told that this is needed to make our configure behave on MacOS 10.7.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
--- Begin Message ---On 06/02/2012, at 7:57 PM, Gert Doering wrote: > Can you send me the changes you had to do? OpenVPN "should" build out of > the box on all supported platforms, and that includes OS X. Here's the diff, it's just three places that AC_LANG_SOURCE needed to be added to AC_COMPILE_IFELSEs as per the change described in http://lists.gnu.org/archive/html/autoconf/2010-09/msg00069.html (changelog for 2.68).
openvpn-testing-autoconf-2.6.8.diff
Description: Binary data> On Mon, Feb 06, 2012 at 01:39:04PM +1000, Byron Ellacott wrote: >> Yep, debian stable, and a client system of OS X 10.7. I had to change a few >> things in acinclude.m4 to get openvpn-testing to build for OS X, due to the >> version of autoconf on the system, and I had to extend the permitted netbits >> further to accommodate the /116 I have, but after that, the VPN connected >> and started passing IPv6 traffic. >> >> (Next problem: my /116 is not routed, the remote end gets NDs that the linux >> kernel cannot or will not pass through to an internal interface, but that's >> nothing to do with OpenVPN). > > If you only have a single IPv6 network, and a incomplete to that, it > might be more straightforward to run OpenVPN in tap mode and bridge > between "eth0" and "tap0" on the server. I'd looked very briefly at whether tap mode would work better in this case, and it almost certainly will. My aim is to demonstrate a VPN that supports both IPv6 and two-factor authentication, so I'll probably give bridge mode a go to demonstrate packets can pass, then call it a success. > "tun" and "server-ipv6" really is meant for routed subnets, not for > addressess stolen from a subnet used on a different interface (you can > do that with proxy-ND, but I'm not sure how to do that on Linux) The subnet is only a /116, but it's not in use on eth0. It's not routed, because it's supposed to be used if you have more than one virtual host in the pool and want to assign addresses according to your own scheme, so another approach I could take to get packets flowing is to use an ND proxy daemon. > Much better: complain to your provider to give you a reasonable network, > like a /56, and use one /64 on the LAN and another /64 for openvp-tun .-) Yes, this would be better. When we (eventually) deploy a v6 VPN for production, it will be using APNIC's own address space, and we'll provide ourselves with a proper /64. In the case of linode, their initial proposal was to offer a /128 and nothing more. Given it's native v6, it's still a step up from a thousand other virtual hosting companies :-) Byron
--- End Message ---
pgpShxXmG6Gf1.pgp
Description: PGP signature
