1 robinkrens.nl - TINC as a gateway
4 Tinc is a VPN daemon which tunnels IP packets and Ethernet frames over UDP. More on Tinc can be found on: http://tinc-vpn.org
5 Here I will show a tinc setup with an *alpha* (as a listening peer) and a *beta* (a peer connecting to alpha). After setting up the VPN, alpha will be the gateway for beta. All traffic from beta will be routed through alpha and back. I will basically retell the man page documentation: https://tinc-vpn.org/documentation-1.1/tinc.conf.5 but in a more tutorial kind of way.
15 _/etc/tinc/gatewayvpn/tinc.conf_
20 The name will be used by other tinc daemons for identification. Device in here means the virtual network to bind to. Because we are going to use routing we use a tunneling device. For alpha we don't fill out a ConnectTo option, so alpha will passively listen for incoming connections.
22 _/etc/tinc/gatewayvpn/tinc-up_
25 ip link set $INTERFACE up
26 ip addr add 172.16.16.1/24 dev $INTERFACE
28 This is a shell script executed right after the tinc daemon has been started and has connected to the virtual network device. It should be used to set up the corresponding network interface, but can also be used to start other things (as we show later for routing). $INTERFACE contains the name of our virtual network interface that the tinc daemon uses (in our case gatewayvpn). So later on, if you run tinc, it will show something like:
31 gatewayvpn Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00
32 inet addr:172.16.16.1 P-t-P:172.16.16.1 Mask:255.255.255.0
33 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
35 We use an IP address in the private range: 172.16.16.0/24, but you can use any address that you like (i.e. 10.0.0.0). The /24 means the subnet in which the daemon is going to serve. Here, we assing 172.16.16.1 to alpha.
37 _/etc/tinc/gatewayvpn/tinc-down_
40 ip addr del 172.16.16.1/24 dev $INTERFACE
41 ip link set $INTERFACE down
43 Shell script that will be executed right before the tinc daemon is going to close its connection to the virtual network device. Similar to tinc-up, but in reverse.
46 _/etc/tinc/gatewayvpn/hosts/alpha_
52 This file should be send to all the other peers (only beta in this example). We _create_ this file here so we can automatically add a public key to this file. Since we want beta to connect to alpha we should assign the external IP and port number to it. Make sure this connection is accesible! We set the subnet to 0.0.0.0/0, you can read this as alpha serve on the *whole* internet (as opposed to a limiting it in a local range. If no Port option is specified, the socket will be bound to the standard port 655 of tinc.
58 $ root@alpha tincd -n gatewayvpn --generate-keys
59 Generating 2048 bits keys: ...........
61 Please enter a file to save private RSA key to [/etc/tinc/gatewayvpn/rsa-key.priv]:
62 Please enter a file to save public RSA key to [/etc/tinc/gatewayvpn/hosts/alpha]:
64 Generate public/private RSA keypair. Private key will be written to _/etc/tinc/gatewayvpn/rsa-key.priv_. Public key will be written to all the files in /etc/tinc/gatewayvpn/hosts/*. So after running this command. _/etc/tinc/gatewayvpn/hosts/alpha_ will look like this
70 -----BEGIN RSA PUBLIC KEY-----
72 -----END RSA PUBLIC KEY-----
74 Test your configuration
77 Now alpha is setup. We can test our configuration as follows:
79 root@alpha:~$ tincd -n gatewayvpn --logfile /root/log
82 Logfile should show the following output:
84 root@alpha:~# cat /root/log
85 2018-04-28 04:43:21 tinc.gatewayvpn[9589]: tincd 1.0.26 (Jul 5 2015 23:17:54) starting, debug level 0
86 2018-04-28 04:43:21 tinc.gatewayvpn[9589]: /dev/net/tun is a Linux tun/tap device (tun mode)
87 2018-04-28 04:43:21 tinc.gatewayvpn[9589]: Ready
89 You should also be able to ping to the tunneling device:
91 root@alpha:~$ ping 172.16.16.1
92 PING 172.16.16.1 (172.16.16.1) 56(84) bytes of data.
93 64 bytes from 172.16.16.1: icmp_seq=1 ttl=64 time=0.065 ms
94 64 bytes from 172.16.16.1: icmp_seq=2 ttl=64 time=0.060 ms
96 --- 172.16.16.1 ping statistics ---
97 2 packets transmitted, 2 received, 0% packet loss, time 999ms
98 rtt min/avg/max/mdev = 0.060/0.062/0.065/0.008 ms
100 The tinc daemon is listening on our configured port 7999:
102 root@alpha:~$ netstat -pnaut
103 tcp 0 0 0.0.0.0:7999 0.0.0.0: LISTEN 9828 tincd
104 udp 0 0 0.0.0.0:7999 0.0.0.0: 9828 tincd
114 _/etc/tinc/gatewayvpn/tinc.conf_
120 Beta will connect to alpha, for this connection beta will look in _/etc/tinc/gatewayvpn/hosts/alpha_ and connect to this IP:PORT
122 _/etc/tinc/gatewayvpn/tinc-up_
125 ip link set $INTERFACE up
126 ip addr add 172.16.16.2/24 dev $INTERFACE
128 Beta will get assigned 172.16.16.2
130 _/etc/tinc/gatewayvpn/tinc-down_
133 ip addr del 172.16.16.2/24 dev $INTERFACE
134 ip link set $INTERFACE down
137 _/etc/tinc/gatewayvpn/hosts/beta_
139 Subnet = 172.16.16.2/32
142 We don't need to set a Address. No peer will actively connect to this peer. The subnet will be limited to just the the peer itself, since it is not serving in any local network.
147 tincd -n gatewayvpn --generate-keys
148 Generating 2048 bits keys: ...........
150 Please enter a file to save private RSA key to [/etc/tinc/gatewayvpn/rsa_key.priv]:
151 Please enter a file to save public RSA key to [/etc/tinc/gatewayvpn/hosts/beta]:
153 So now you will also have created the private key file for beta. Public keys are written to files in the host directory.
154 *Note: don't forget to put _/etc/tinc/gatewayvpn/hosts/beta_ on the alpha side and alpha on the beta side.
156 root@beta:/etc/tinc/gatewayvpn/hosts$ sudo scp root@alpha:/etc/tinc/gatewayvpn/hosts/alpha .
157 alpha 100% 481 0.5KB/s 00:00
158 root@beta:/etc/tinc/gatewayvpn/hosts$ sudo scp beta root@alpha:/etc/tinc/gatewayvpn/hosts/
159 beta 100% 463 0.5KB/s 00:00
161 Test your configuration
170 Now let's see if the configuration is correct and both peers' connections are accepted.
171 We, in a sense, have used a very verbose way to make a tunnel between two computers over the internet.
176 root@alpha:~$ tincd -n gatewayvpn --log-file /root/log
181 root@beta:~$ tincd -n gatewayvpn --log-file /root/log
184 Now test if you can ping!
186 root@alpha:~# ping 172.16.16.2
187 PING 172.16.16.2 (172.16.16.2) 56(84) bytes of data.
188 64 bytes from 172.16.16.2: icmp_seq=1 ttl=64 time=118 ms
189 64 bytes from 172.16.16.2: icmp_seq=2 ttl=64 time=118 ms
190 64 bytes from 172.16.16.2: icmp_seq=3 ttl=64 time=118 ms
192 root@beta:~# ping 172.16.16.1
194 PING 172.16.16.1 (172.16.16.1) 56(84) bytes of data.
195 64 bytes from 172.16.16.1: icmp_seq=1 ttl=64 time=118 ms
196 64 bytes from 172.16.16.1: icmp_seq=2 ttl=64 time=118 ms
197 64 bytes from 172.16.16.1: icmp_seq=3 ttl=64 time=117 ms
203 (Note: mostly copied from the tinc manual)
204 It is possible to have one peer forward all of its network traffic to another peer on the VPN, effectively using this peer as the default gateway. This behaviour can configured in the tinc-up or tinc-down scripts. First, we explain some theory about redirecting, then the example scripts will follow.
209 Normally, there are two entries in the routing table. One is the route for the local network, which tells the kernel which IP addresses are directly reachable. The second is the "default gateway", which tells the kernel that in order to reach the rest of the Internet, traffic should be sent to the gateway of the local network. Usually the gateway is a router or firewall device, and its IPv4 address usually ends in .1. An example output of route -n on Linux:
211 Destination Gateway Genmask Flags Metric Ref Use Iface
212 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
213 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
215 Here, the LAN has the IPv4 address range 192.168.1.0/24, and the gateway is 192.168.1.1. Suppose we have a VPN with address range 172.16.16.0/24 (as in our case) on which a server (alpha in our setup) exists with address 172.16.16.1. If we have a VPN connection, and a peer wants to replace the standard default route with a default route pointing to 172.16.16.1, then there is a problem: the kernel does not know anymore how to send the encapsulated VPN packets to the server anymore. So we need to add an exception for traffic to the real (remote) IP address of the VPN server. Suppose its real address is 1.2.3.4, then the routing table should become:
217 Kernel IP routing table
218 Destination Gateway Genmask Flags Metric Ref Use Iface
219 172.16.16.1 0.0.0.0 255.255.255.255 UH 0 0 0 gatewayvpn
220 1.2.3.4 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
221 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
222 0.0.0.0 172.16.16.1 0.0.0.0 UG 0 0 0 gatewayvpn
224 This will ensure the local LAN is reachable, that the VPN server's real IP address is reachable via the original gateway, that the VPN server's VPN IP address is reachable on the vpn interface, and that all other traffic goes via the server on the VPN.
226 It is better not to remove the original default gateway route, since someone might kill the tincd process, such that it doesn't get a chance to restore the original. Instead, we use a trick where we add two /1 routes instead of one /0 route:
228 Kernel IP routing table
229 Destination Gateway Genmask Flags Metric Ref Use Iface
230 172.16.16.1 0.0.0.0 255.255.255.255 UH 0 0 0 gatewayvpn
231 1.2.3.4 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
232 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
233 128.0.0.0 172.16.16.1 128.0.0.0 UG 0 0 0 gatewayvpn
234 0.0.0.0 172.16.16.1 128.0.0.0 UG 0 0 0 gatewayvpn
235 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
237 Since both /1 cover all possible addresses, the real default route will never be used while the two /1 routes are present.
242 To achieve this, two scripts are needed on beta. We can add the following code to the the already existing tinc-up and tinc-down files.
244 _/etc/tinc/gatewayvpn/tinc-up_
247 VPN_GATEWAY=172.16.16.1
248 REMOTEADDRESS=1.2.3.4
249 ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
251 ip route add $REMOTEADDRESS $ORIGINAL_GATEWAY
252 ip route add $VPN_GATEWAY dev $INTERFACE
253 ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
254 ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
256 _/etc/tinc/gatewayvpn/tinc-down_
259 ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
260 REMOTEADDRESS=1.2.3.4
262 ip route del $REMOTEADDRESS $ORIGINAL_GATEWAY
263 ip route del $VPN_GATEWAY dev $INTERFACE
264 ip route del 0.0.0.0/1 dev $INTERFACE
265 ip route del 128.0.0.0/1 dev $INTERFACE
267 These script use the iproute2 commands, because they are easier to work with. The VPN_GATEWAY and REMOTEADDRESS variables have to be filled in by hand. The ORIGINAL_GATEWAY variable copies the relevant information from the original default route to create the exception route to the VPN server.
273 Make sure forwarding is enabled on alpha. Make sure you have masquerading or another form of routing set up on alpha. If you don't masquerade outgoing (forwarded beta) packets, the source address in in the TCP/UDP package will still remain 172.16.16.2. Please have a look here: http://www.tldp.org/LDP/nag2/x-087-2-ipmasq.html if you don't know about NAT and masquerading.
276 # iptables config line to masquerade
278 echo "Enabling IPv4 forwarding"
279 echo 1 >/proc/sys/net/ipv4/ip_forward
281 echo "Appending Masquerade rule to iptables"
282 iptables -t nat -A POSTROUTING -s 172.16.16.0/255.255.255.0 -o eth0 -j MASQUERADE
284 Here I use iptables to masquerade the (-s) source address on the (-o) interface eth0.
290 Restart the daemon on alpha and beta. Use route -n to see check your routing table on beta. It should look similar to the one that is displayed above. Ping both the 172.16.16.1 and 1.2.3.4 (external address). In case of problems, trace the connections or analyze the data with tools like wireshark.
296 * DNS request are not forwarded through the gateway. Check your resolver config files (/etc/resolv.conf). Debian-based systems might have the following configuration
298 root@beta:~$ cat /etc/resolv.conf
302 * and in your routing table you might have the following entry. A local / caching DNS server might still send packages to your router. Use wireshark to see if there are any DNS queries, not going to the VPN gateway
305 link-local * 255.255.0.0 U 1000 0 0 wlp7s0
307 * A simple fix would to change your resolv.conf and point it to nameserver 8.8.8.8
309 * Check your logfile while running tinc (i.e. you might forgot to create a key pair):
311 2018-04-28 04:49:53 tinc.gatewayvpn[9684]: Error reading RSA private key file
312 `/etc/tinc/gatewayvpn/rsa_key.priv': No such file or directory
314 * Overview of created files
316 root@alpha:~$ ls -R /etc/tinc/gatewayvpn
317 /etc/tinc/gatewayvpn:
318 hosts/ rsa-key.priv tinc.conf tinc-down tinc-up
319 /etc/tinc/gatewayvpn/hosts:
322 root@beta:~$ ls -R /etc/tinc/gatewayvpn
323 /etc/tinc/gatewayvpn:
324 hosts/ rsa-key.priv tinc.conf tinc-down tinc-up
325 /etc/tinc/gatewayvpn/hosts:
328 * Use tcpdump or wireshark to analyze your network devices