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 1SAP3b-0005ey-Tw for garchives@archives.gentoo.org; Wed, 21 Mar 2012 17:10:44 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EE81EE0B2C; Wed, 21 Mar 2012 17:10:32 +0000 (UTC) Received: from saya.mjhnosekai.com (mail.mjhnosekai.com [64.20.39.34]) by pigeon.gentoo.org (Postfix) with ESMTP id F23CBE082D for ; Wed, 21 Mar 2012 17:08:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by saya.mjhnosekai.com (Postfix) with ESMTP id 33D9A6C1495 for ; Wed, 21 Mar 2012 13:08:43 -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 9fX7r8yQt6KA for ; Wed, 21 Mar 2012 13:08:41 -0400 (EDT) Received: from saya.mjhnosekai.com (saya.mjhnosekai.com [64.20.39.34]) by saya.mjhnosekai.com (Postfix) with ESMTP id 8BA7A6C14B7 for ; Wed, 21 Mar 2012 13:08:41 -0400 (EDT) Date: Wed, 21 Mar 2012 13:08:41 -0400 (EDT) From: "Michael J. Hill" To: gentoo-user@lists.gentoo.org Message-ID: <290276592.664.1332349721374.JavaMail.root@saya.mjhnosekai.com> In-Reply-To: <201203210937.53599.michaelkintzios@gmail.com> Subject: Re: [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_663_1448453912.1332349721372" X-Originating-IP: [74.105.180.250] X-Mailer: Zimbra 7.1.4_GA_2555 (ZimbraWebClient - FF3.0 (Win)/7.1.4_GA_2555) X-Archives-Salt: eccc9136-1456-4d78-a3eb-490195e26cd2 X-Archives-Hash: a1fbe6e65b2e929a6d9448e94d653896 ------=_Part_663_1448453912.1332349721372 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit From: "Mick" To: gentoo-user@lists.gentoo.org Sent: Wednesday, March 21, 2012 5:37:51 AM Subject: Re: [gentoo-user] PPP Tunnel using iproute2/tun interface On Wednesday 21 Mar 2012 02:05:03 Michael J. Hill wrote: > 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: Shouldn't you create the ipip tunnel here first? Something like: iptunnel_tun0="mode ipip remote 172.18.0.1 ttl 255" #not sure if local is required, you can try with & without. > link_tun0="ipsec0" #Not sure this is correct, shouldn't it be an iface? > 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 -- Regards, Mick ----- Original Message ----- Thanks for the help. It did give me some insight on where to look next, and now it works perfectly. The problem was in part the ordering I was using, and more specific, iptunnel_tun0_mode should have been iptunnel_tun0="mode xxxxxx". That would've resulted in the creation of the interface. I've included my final config for anybody else who may be interested in such a setup: link_tun0="ipsec0" 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}" mtu_tun0="1500" 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 1 " rules_tun0="fwmark 1 table 1" rc_net_tun0_need="ipsec" preup() { ip link show dev ${IFACE} 2>/dev/null || return 0 } ------=_Part_663_1448453912.1332349721372 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'>From: "Mick" <michaelkintzios@gmail.com>
To: gent= oo-user@lists.gentoo.org
Sent: Wednesday, March 21, 2012 5:37:51 = AM
Subject: Re: [gentoo-user] PPP Tunnel using iproute2/tun inter= face

On Wednesday 21 Mar 2012 02:05:03 Michael J. Hill wrote:
>= ; Hello,
>
> In testing, I have gotten this setup to work by m= anually completing the
> necessary steps; however, I am now looking t= o have everything completed
> automatically so as to ensure my setup = persists over a reboot.
>
> Firstly, an outline of what I am d= oing:
> * I have a Gentoo VM running at home, functioning as my firew= all/router,
> which works perfectly fine. * Said VM has established a= n IPSEC tunnel to a
> dedicated server using OpenSWAN. This also work= s perfectly fine. * A tun0
> interface is created on both devices, se= tting up an IPIP PPP tunnel that
> sits on top of the IPSEC tunnel. *= Firewall and Routing rules are in place
> to perform policy-based ro= uting over this tun0 interface. This again,
> works perfectly fine.>
> For the rest, the following configuration is worth noting:<= br>> * The dedicated server is running CentOS 6, not that this is of nec= essary
> import for this configuration. * 172.18.0.1 resides on the d= edicated
> server.
> * 10.0.0.1 is the management IP of my Gent= oo VM, and serves as its identity
> as well. * 172.18.1.0/24 is the n= etwork utilized for the tunnel, with
> 172.18.1.1 on the dedicated se= rver, and 172.18.1.2 on the Gentoo VM.
>
> In effect, the firs= t 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 rig= ht 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 li= nk 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 i= f the IPSEC tunnel is up and running. That being
> said, I added the = following to /etc/conf.d/net:

Shouldn't you create the ipip tunnel = here first?

Something like:

iptunnel_tun0=3D"mode ipip remote= 172.18.0.1 ttl 255" #not sure if local is
required, you can try with &= amp; without.


> link_tun0=3D"ipsec0"  #Not sure this is = correct, shouldn't it be an iface?

> config_tun0=3D"172.18.1.2 ne= tmask 255.255.255.0 brd 172.18.1.255"
> dns_servers_tun0=3D"10.0.1.2"=
> routes_tun0=3D(
> "64.20.39.38/32 via 172.18.1.1"
> "d= efault via 172.18.1.1 table ipsec"
> )
> mtu_tun0=3D"1500"
&= gt; iptunnel_tun0_remote=3D"172.18.0.1"
> iptunnel_tun0_local=3D"10.0= .0.1"
> iptunnel_tun0_mode=3D"ipip remote ${iptunnel_tun0_remote} loc= al
> ${iptunnel_tun0_local} dev ${link_tun0}" rc_net_tun0_need=3D"ips= ec"
> 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 inter= face. I've tested with and
> without this, and it doesn't work. Attem= pting to bring up the interface
> using rc-service results in the fol= lowing error: Cannot find device "tun0"
> * ERROR: interface tun0 doe= s not exist
> * Ensure that you have loaded the correct kernel module= for your hardware
> * ERROR: net.tun0 failed to start
>
&g= t; I could easily script all this out, and probably call it through rc.loca= l,
> but I'd rather be able to utilize the dependency resolution to m= ake sure
> all the necessary components are up.
>
> Any = insights on getting it to behave?
>
> Michael Hill

-- <= br>Regards,
Mick

Thanks for the help. = ; It did give me some insight on where to look next, and now it works perfe= ctly.  The problem was in part the ordering I was using, and more spec= ific, iptunnel_tun0_mode should have been iptunnel_tun0=3D"mode xxxxxx".&nb= sp; That would've resulted in the creation of the interface.  I've inc= luded my final config for anybody else who may be interested in such a setu= p:

link_tun0=3D"ipsec0"
iptunnel_tun0_remote=3D"172.18.0.1"
ip= tunnel_tun0_local=3D"10.0.0.1"
iptunnel_tun0=3D"mode ipip remote ${iptun= nel_tun0_remote} local ${iptunnel_tun0_local} dev ${link_tun0}"
mtu_tun0= =3D"1500"
config_tun0=3D"172.18.1.2 netmask 255.255.255.0 brd 172.18.1.2= 55"
dns_servers_tun0=3D"10.0.1.2"
routes_tun0=3D"64.20.39.38/32 via 1= 72.18.1.1
 default via 172.18.1.1 table 1"
rules_tun0=3D"fwmark = 1 table 1"

rc_net_tun0_need=3D"ipsec"

preup() {
  ip = link show dev ${IFACE} 2>/dev/null || return 0
}
------=_Part_663_1448453912.1332349721372--