From owner-freebsd-current@freebsd.org Tue Nov 3 09:39:40 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CBB0FA1EB55 for ; Tue, 3 Nov 2015 09:39:40 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 2657719D6 for ; Tue, 3 Nov 2015 09:39:39 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 72118 invoked by uid 89); 3 Nov 2015 09:32:57 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@88.217.180.132) by mail.grem.de with ESMTPA; 3 Nov 2015 09:32:57 -0000 Date: Tue, 3 Nov 2015 10:32:53 +0100 From: Michael Gmelin To: Craig Rodrigues Cc: George Neville-Neil , Randall Stewart , Alfred Perlstein , freebsd-current Current Subject: Re: Tunnelling IPv4 over IPv6 for GitHub access? Message-ID: <20151103103253.02e00a7a@bsd64.grem.de> In-Reply-To: References: <20151103005019.4250d920@bsd64.grem.de> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; amd64-portbld-freebsd10.2) X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 09:39:41 -0000 On Mon, 2 Nov 2015 19:29:39 -0800 Craig Rodrigues wrote: > On Mon, Nov 2, 2015 at 3:50 PM, Michael Gmelin > wrote: > > > > > > > > On Mon, 2 Nov 2015 14:04:18 -0800 > > > > ikvjwd.com once offered a service using haproxy, you can find their > > configuration here: > > > > > https://github.com/rcsheets/ikvjwd/commit/58979dcaf42fbbd9203067a6ba4629ba01469120 > > > > We were using ikvjwd.com, but that service did not seem to be very > reliable. > > > > > > Another way to tunnel all IPv4 traffic is set up an OpenVPN server > > on a dual stack machine and route your client IPv4 traffic over it > > (that approach is actually very easy to accomplish, stable and will > > work with any service). > > > > Can you point me to some docs for how to do this? This could work > for me. > > I have two separate networks that are connected: > > +--------------+ +--------------+ > | | | | > | | | | > | Dual +---------> | IPv6 | > | stack | | only | > | | | | > +--------------+ +--------------+ > > > My machine is in the IPv6 only network, but it has access to > a dual stack network. I still need to run my stuff which accesses > GitHub in the IPv6 only network. Basic guide for a point to point connection (this assumes that the client machine on your IPv6 only network still has an IPv4 stack in the kernel - also, if all you want is proxying one website [github http], setting up a proxy might make more sense): Install and enable openvpn on both machines pkg install openvpn setrc openvpn_enable=YES Example config side A (client): Fixed tunnel interface in rc.conf (so you can use tun8 in firewall rules cloned_interfaces="tun8" ifconfig_tun8="inet 10.10.10.1 10.10.10.2" /usr/local/etc/openvpn.conf: tls-client dev tun8 verb 3 remote hostnameOrIpv6AddressToConnectTo 1294 proto udp6 ca /usr/local/etc/openvpn/ca.crt cert /usr/local/etc/openvpn/client.crt key /usr/local/etc/openvpn/client.key tls-auth /usr/local/etc/openvpn/ta.key 1 ifconfig 10.10.10.1 10.10.10.2 # add IPv4 networks you want to route over the tunnel # you can also use static routed in rc.conf instead # or push the routes from the server side: route 141.1.1.0 255.255.255.0 keepalive 10 60 ping-timer-rem user nobody group nobody persist-key persist-tun daemon tun-mtu-extra 6 Example server side B (dual stack in your case): Fixed tunnel interface in rc.conf (so you can use tun8 in firewall rules cloned_interfaces="tun8" ifconfig_tun8="inet 10.10.10.2 10.10.10.1" /usr/local/etc/openvpn.conf: tls-server dev tun8 verb 3 local IpV6AddressToListenTo port 1294 proto udp6 ca /usr/local/etc/openvpn/ca.crt cert /usr/local/etc/openvpn/server.crt key /usr/local/etc/openvpn/server.key dh /usr/local/etc/openvpn/dh4096.pem tls-auth /usr/local/etc/openvpn/ta.key 0 ifconfig 10.10.10.2 10.10.10.1 # routes to send the other direction (optional) # ... keepalive 10 60 ping-timer-rem user nobody group nobody persist-key persist-tun daemon tun-mtu-extra 6 tun-mtu-extra was required in my setup, you might not need it. tls-auth is optional (it allows openvpn to hide, which you probably won't need on your local network). If you don't want to create a set of certificates and/or security is secondary, you can save yourself the work of creating all the certificates and replace it with a static shared secret. In this case ca cert key can be removed and replaced with "secret filename". filename is generated using "openvpn --genkey --secret filename". You then need some firewall rule to NAT the traffic that comes over the tunnel on the server side. If you have multiple clients, it's better to switch to an address pool (e.g. server 10.8.0.0 255.255.255.0). In that case I would recommend to push all relevant routes to the client (push "route ip netmask" in the server config) and not bother to use a fixed tunnel interface on the client side (so no entry in rc.conf and change "tun8" to "tun" in the client configuration). It's really not as complicated as my description makes it look like :p You can find plenty of examples on openvpn.net, including a long example configuration that details all options: https://openvpn.net/index.php/open-source/documentation/howto.html#examples There are plenty of howtos out there. I've been using this for a few years now to circumvent a broken DS-LITE gateway outbound and allow IPv4 connectivity inbound, it's stable and performs well. - Michael -- Michael Gmelin