Tunnelling can be used for various purposes. If you need a server or an application to have a leg in another network or you just want to disguise where your traffic originates from, tunnelling is very useful. To do it, you will need at least one (master) server that runs the application and at least one remote (node) server on another network. You can have many nodes tunnelled to the same master server allowing your application for example Power MTA to have many separate domains configured on different networks while pointing to the same server.

tunnel2
Image Source – Tony Webster (CC0)

What you need to do:

Phase 1

1. Make sure you have loaded the tunnelling module into the kernel with the modprobe command on both servers:

modprobe tun

2. You need to create as many alias interfaces as you need on both ends with their corresponding ip addresses by using the ifconfig command or editing the interface configuration files “ifcfg-eth0-range0”:

IPADDR_START=192.168.0.1
IPADDR_END=192.168.0.6
NETMASK=255.255.255.248
CLONENUM_START=0

3. You need to create as many ipip point-to-point tunnel (tunX) for the kernel as many nodes you have by using the ip command. On the node end change the local<->remote ips respectively:

ip tunnel add tun0 mode ipip remote 5.6.7.8 local 1.2.3.4

4. You need to configure up as many tunnel interfaces as you have created with tunnel endpoint ip addresses eg. 192.168.254.1 to 192.168.254.2 on both servers (master and node) swapping the local/remote respectively:

fconfig tun0 192.168.254.1 netmask 255.255.255.252 pointopoint 192.168.254.2

Phase 2

5. You need to set the MTU for the tunnel interface(s) with the ifconfig command on both servers:

ifconfig tun0 mtu 1500 up

6. You need to setup the link for the tunnel interface(s) with the ip command:

ip link set tun0 up

7. At this point you should be able to ping the other end of the tunnel. Eg. on 1.2.3.4 the “ping 192.168.254.2” command should reply and vice versa.

8. You need to create an empty routing table on the master server for this tunnel/node by editing the routing configuration in “/etc/iproute2/rt_tables” by adding the following:

100 route_tun0

capture2Image Source – Piotr Lohunko (CC0)

Phase 3

9. You need to add a default route into the new empty routing table (route_tun0) pointing to 192.168.254.2:

ip route add default via 192.168.254.2 dev tun0 table route_tun0

10. You need to add an ip rule that tells the kernel which routing table to use (route_tun0) in case the source ip is 192.168.0.1 as many times as many ip addresses you want to send through the tunnel you have configured:

ip rule add from 192.168.0.1 table route_tun0

11. On the node end set the default route for 192.168.0.0/29 to tun0 to send back the traffic to the master server:

route add -net 192.168.0.0/29 dev tun0
12. Enable ip packet forwarding with either the sysctl command or editing its configuration or modifying the kernel parameter on the fly on the node:

sysctl -w net.ipv4.ip_forward=1

Phase 4

13. Now you need to setup the SNAT rules in the POSTROUTING table and DNAT rules in the PREROUTING table using iptables for all ip addresses you need to mask (eg 192.168.0.1 to 5.6.7.11 and vice versa) on the node server:

  • iptables -t nat -A POSTROUTING -s 192.168.0.1 -j SNAT –to-source 5.6.7.11
  • iptables -t nat -A PREROUTING -d 5.6.7.11 -j DNAT –to-destination 192.168.0.1

14. You might want to disable and shut-down all services running on the node end and listening on the alias ip addresses as those services may interfere with the services running on the master server.

15. To verify your setup you can use the tcpdump command on the master server to listen for traffic for a specific address eg 192.168.0.1. You should see traffic back and forth on a specific internal address while you are addressing the external ip address of the node. Eg. you ping 5.6.7.11 from the internet then tcpdump should show traffic on the master server for ip 192.168.0.1.

16. If you want to make your configuration permanent you can create a script file and configure it to run on boot with the chkconfig command. You can create separate scripts per tunnel as well if you wish just make sure they are configured to run at boot otherwise you will need to run this by hand after a reboot.

If you’d like to talk further about this process, get in touch with the Veber team today to see how we can help you!

Veber are specialists in dedicated server hosting. Get in contact today and our team will show you how we can help your business.

CTA banner (002)

Featured Blog Posts

Comments are closed.