Gentoo Archives: gentoo-user

From: "Michael J. Hill" <mjhill@××××××××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] PPP Tunnel using iproute2/tun interface
Date: Wed, 21 Mar 2012 17:10:44
Message-Id: 290276592.664.1332349721374.JavaMail.root@saya.mjhnosekai.com
In Reply to: Re: [gentoo-user] PPP Tunnel using iproute2/tun interface by Mick
1 From: "Mick" <michaelkintzios@×××××.com>
2
3 To: gentoo-user@l.g.o
4 Sent: Wednesday, March 21, 2012 5:37:51 AM
5 Subject: Re: [gentoo-user] PPP Tunnel using iproute2/tun interface
6
7 On Wednesday 21 Mar 2012 02:05:03 Michael J. Hill wrote:
8 > Hello,
9 >
10 > In testing, I have gotten this setup to work by manually completing the
11 > necessary steps; however, I am now looking to have everything completed
12 > automatically so as to ensure my setup persists over a reboot.
13 >
14 > Firstly, an outline of what I am doing:
15 > * I have a Gentoo VM running at home, functioning as my firewall/router,
16 > which works perfectly fine. * Said VM has established an IPSEC tunnel to a
17 > dedicated server using OpenSWAN. This also works perfectly fine. * A tun0
18 > interface is created on both devices, setting up an IPIP PPP tunnel that
19 > sits on top of the IPSEC tunnel. * Firewall and Routing rules are in place
20 > to perform policy-based routing over this tun0 interface. This again,
21 > works perfectly fine.
22 >
23 > For the rest, the following configuration is worth noting:
24 > * The dedicated server is running CentOS 6, not that this is of necessary
25 > import for this configuration. * 172.18.0.1 resides on the dedicated
26 > server.
27 > * 10.0.0.1 is the management IP of my Gentoo VM, and serves as its identity
28 > as well. * 172.18.1.0/24 is the network utilized for the tunnel, with
29 > 172.18.1.1 on the dedicated server, and 172.18.1.2 on the Gentoo VM.
30 >
31 > In effect, the first thing I need to do, is automate the IPIP PPP tunnel
32 > setup so that the device can persist over a reboot. I can create it
33 > manually right now, no problem, with the following command strings: # ip
34 > tunnel add tun0 mode ipip remote 172.18.0.1 local 10.0.0.1
35 > # ip addr add 172.18.1.2/24 dev tun0
36 > # ip link set tun0 mtu 1500
37 > # i p link set tun0 up
38 >
39 > This all works perfectly fine, and tun0 is created after running the first
40 > command. Now I need this to persist a reboot. I wanted to handle this
41 > through OpenRC, since I can then do dependency resolution, and make sure
42 > the tunnel comes up only if the IPSEC tunnel is up and running. That being
43 > said, I added the following to /etc/conf.d/net:
44
45 Shouldn't you create the ipip tunnel here first?
46
47 Something like:
48
49 iptunnel_tun0="mode ipip remote 172.18.0.1 ttl 255" #not sure if local is
50 required, you can try with & without.
51
52
53 > link_tun0="ipsec0" #Not sure this is correct, shouldn't it be an iface?
54
55 > config_tun0="172.18.1.2 netmask 255.255.255.0 brd 172.18.1.255"
56 > dns_servers_tun0="10.0.1.2"
57 > routes_tun0=(
58 > "64.20.39.38/32 via 172.18.1.1"
59 > "default via 172.18.1.1 table ipsec"
60 > )
61 > mtu_tun0="1500"
62 > iptunnel_tun0_remote="172.18.0.1"
63 > iptunnel_tun0_local="10.0.0.1"
64 > iptunnel_tun0_mode="ipip remote ${iptunnel_tun0_remote} local
65 > ${iptunnel_tun0_local} dev ${link_tun0}" rc_net_tun0_need="ipsec"
66 > preup() {
67 > # If the link does not exist, return now, it's a tunnel!
68 > ip link show dev ${IFACE} 2>/dev/null || return 0
69 > }
70 >
71 > Now, the configuration does reflect an additional item not in my original
72 > setup, which links tun0 to the ipsec0 interface. I've tested with and
73 > without this, and it doesn't work. Attempting to bring up the interface
74 > using rc-service results in the following error: Cannot find device "tun0"
75 > * ERROR: interface tun0 does not exist
76 > * Ensure that you have loaded the correct kernel module for your hardware
77 > * ERROR: net.tun0 failed to start
78 >
79 > I could easily script all this out, and probably call it through rc.local,
80 > but I'd rather be able to utilize the dependency resolution to make sure
81 > all the necessary components are up.
82 >
83 > Any insights on getting it to behave?
84 >
85 > Michael Hill
86
87 --
88 Regards,
89 Mick
90
91 ----- Original Message -----
92 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:
93
94 link_tun0="ipsec0"
95 iptunnel_tun0_remote="172.18.0.1"
96 iptunnel_tun0_local="10.0.0.1"
97 iptunnel_tun0="mode ipip remote ${iptunnel_tun0_remote} local ${iptunnel_tun0_local} dev ${link_tun0}"
98 mtu_tun0="1500"
99 config_tun0="172.18.1.2 netmask 255.255.255.0 brd 172.18.1.255"
100 dns_servers_tun0="10.0.1.2"
101 routes_tun0="64.20.39.38/32 via 172.18.1.1
102 default via 172.18.1.1 table 1 "
103 rules_tun0="fwmark 1 table 1"
104
105 rc_net_tun0_need="ipsec"
106
107 preup() {
108 ip link show dev ${IFACE} 2>/dev/null || return 0
109 }