From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SAAxW-00080B-AE for garchives@archives.gentoo.org; Wed, 21 Mar 2012 02:07:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D7692E09F7; Wed, 21 Mar 2012 02:06:59 +0000 (UTC) Received: from saya.mjhnosekai.com (mail.mjhnosekai.com [64.20.39.34]) by pigeon.gentoo.org (Postfix) with ESMTP id B4B96E0950 for ; Wed, 21 Mar 2012 02:05:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by saya.mjhnosekai.com (Postfix) with ESMTP id C687E6C2FD2 for ; Tue, 20 Mar 2012 22:05:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at mjhnosekai.com Received: from saya.mjhnosekai.com ([127.0.0.1]) by localhost (saya.mjhnosekai.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q17ICHkwbUAw for ; Tue, 20 Mar 2012 22:05:03 -0400 (EDT) Received: from saya.mjhnosekai.com (saya.mjhnosekai.com [64.20.39.34]) by saya.mjhnosekai.com (Postfix) with ESMTP id 672B86C2FEE for ; Tue, 20 Mar 2012 22:05:03 -0400 (EDT) Date: Tue, 20 Mar 2012 22:05:03 -0400 (EDT) From: "Michael J. Hill" To: gentoo-user@lists.gentoo.org Message-ID: <65496747.528.1332295503067.JavaMail.root@saya.mjhnosekai.com> In-Reply-To: <362848389.415.1332294553410.JavaMail.root@saya.mjhnosekai.com> Subject: [gentoo-user] PPP Tunnel using iproute2/tun interface Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_527_1017717186.1332295503066" X-Originating-IP: [209.235.223.163] X-Mailer: Zimbra 7.1.4_GA_2555 (ZimbraWebClient - FF3.0 (Win)/7.1.4_GA_2555) X-Archives-Salt: ff20a8a4-6533-404b-a2aa-644aee0f9664 X-Archives-Hash: d0a8ec5f73ec6b28f736b86e2029dbc0 ------=_Part_527_1017717186.1332295503066 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hello, In testing, I have gotten this setup to work by manually completing the necessary steps; however, I am now looking to have everything completed automatically so as to ensure my setup persists over a reboot. Firstly, an outline of what I am doing: * I have a Gentoo VM running at home, functioning as my firewall/router, which works perfectly fine. * Said VM has established an IPSEC tunnel to a dedicated server using OpenSWAN. This also works perfectly fine. * A tun0 interface is created on both devices, setting up an IPIP PPP tunnel that sits on top of the IPSEC tunnel. * Firewall and Routing rules are in place to perform policy-based routing over this tun0 interface. This again, works perfectly fine. For the rest, the following configuration is worth noting: * The dedicated server is running CentOS 6, not that this is of necessary import for this configuration. * 172.18.0.1 resides on the dedicated server. * 10.0.0.1 is the management IP of my Gentoo VM, and serves as its identity as well. * 172.18.1.0/24 is the network utilized for the tunnel, with 172.18.1.1 on the dedicated server, and 172.18.1.2 on the Gentoo VM. In effect, the first thing I need to do, is automate the IPIP PPP tunnel setup so that the device can persist over a reboot. I can create it manually right now, no problem, with the following command strings: # ip tunnel add tun0 mode ipip remote 172.18.0.1 local 10.0.0.1 # ip addr add 172.18.1.2/24 dev tun0 # ip link set tun0 mtu 1500 # i p link set tun0 up This all works perfectly fine, and tun0 is created after running the first command. Now I need this to persist a reboot. I wanted to handle this through OpenRC, since I can then do dependency resolution, and make sure the tunnel comes up only if the IPSEC tunnel is up and running. That being said, I added the following to /etc/conf.d/net: link_tun0="ipsec0" config_tun0="172.18.1.2 netmask 255.255.255.0 brd 172.18.1.255" dns_servers_tun0="10.0.1.2" routes_tun0=( "64.20.39.38/32 via 172.18.1.1" "default via 172.18.1.1 table ipsec" ) mtu_tun0="1500" iptunnel_tun0_remote="172.18.0.1" iptunnel_tun0_local="10.0.0.1" iptunnel_tun0_mode="ipip remote ${iptunnel_tun0_remote} local ${iptunnel_tun0_local} dev ${link_tun0}" rc_net_tun0_need="ipsec" preup() { # If the link does not exist, return now, it's a tunnel! ip link show dev ${IFACE} 2>/dev/null || return 0 } Now, the configuration does reflect an additional item not in my original setup, which links tun0 to the ipsec0 interface. I've tested with and without this, and it doesn't work. Attempting to bring up the interface using rc-service results in the following error: Cannot find device "tun0" * ERROR: interface tun0 does not exist * Ensure that you have loaded the correct kernel module for your hardware * ERROR: net.tun0 failed to start I could easily script all this out, and probably call it through rc.local, but I'd rather be able to utilize the dependency resolution to make sure all the necessary components are up. Any insights on getting it to behave? Michael Hill ------=_Part_527_1017717186.1332295503066 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: verdana,helvetica,sans-serif; font-size: 10pt; co= lor: #000000'>Hello,

In testing, I have gotten this setup to work by= manually completing the necessary steps; however, I am now looking to have= everything completed automatically so as to ensure my setup persists over = a reboot.

Firstly, an outline of what I am doing:
* I have a Gent= oo VM running at home, functioning as my firewall/router, which works perfe= ctly fine.
* Said VM has established an IPSEC tunnel to a dedicated serv= er using OpenSWAN.  This also works perfectly fine.
* A tun0 interf= ace is created on both devices, setting up an IPIP PPP tunnel that sits on = top of the IPSEC tunnel.
* Firewall and Routing rules are in place to pe= rform policy-based routing over this tun0 interface.  This again, work= s perfectly fine.

For the rest, the following configuration is worth= noting:
* The dedicated server is running CentOS 6, not that this is of= necessary import for this configuration.
* 172.18.0.1 resides on the de= dicated server.
* 10.0.0.1 is the management IP of my Gentoo VM, and ser= ves as its identity as well.
* 172.18.1.0/24 is the network utilized for= the tunnel, with 172.18.1.1 on the dedicated server, and 172.18.1.2 on the= Gentoo VM.

In effect, the first thing I need to do, is automate the= IPIP PPP tunnel setup so that the device can persist over a reboot.  = I can create it manually right now, no problem, with the following command = strings:
# ip tunnel add tun0 mode ipip remote 172.18.0.1 local 10.0.0.1=
# ip addr add 172.18.1.2/24 dev tun0
# ip link set tun0 mtu 1500
= # ip link set tun0 up

This all works perfectly fine, and tun0 is cre= ated after running the first command.  Now I need this to persist a re= boot.  I wanted to handle this through OpenRC, since I can then do dep= endency resolution, and make sure the tunnel comes up only if the IPSEC tun= nel is up and running.  That being said, I added the following to /etc= /conf.d/net:
link_tun0=3D"ipsec0"
config_tun0=3D"172.18.1.2 netmask 2= 55.255.255.0 brd 172.18.1.255"
dns_servers_tun0=3D"10.0.1.2"
routes_t= un0=3D(
 "64.20.39.38/32 via 172.18.1.1"
 "default via 172.= 18.1.1 table ipsec"
)
mtu_tun0=3D"1500"
iptunnel_tun0_remote=3D"17= 2.18.0.1"
iptunnel_tun0_local=3D"10.0.0.1"
iptunnel_tun0_mode=3D"ipip= remote ${iptunnel_tun0_remote} local ${iptunnel_tun0_local} dev ${link_tun= 0}"
rc_net_tun0_need=3D"ipsec"
preup() {
  # If the link does= not exist, return now, it's a tunnel!
  ip link show dev ${IFACE} = 2>/dev/null || return 0
}

Now, the configuration does reflect = an additional item not in my original setup, which links tun0 to the ipsec0= interface.  I've tested with and without this, and it doesn't work.&n= bsp; Attempting to bring up the interface using rc-service results in the f= ollowing error:
Cannot find device "tun0"
 *   ERROR: = interface tun0 does not exist
 *   Ensure that you have l= oaded the correct kernel module for your hardware
 * ERROR: net.tun= 0 failed to start

I could easily script all this out, and probably c= all it through rc.local, but I'd rather be able to utilize the dependency r= esolution to make sure all the necessary components are up.

Any insi= ghts on getting it to behave?

Michael Hill

------=_Part_527_1017717186.1332295503066--