www.tinc-vpn.org Git - wiki/blob - examples/redirect-gateway.mdwn

   1 [[!meta title="redirect-gateway"]]
   2
   3 ## Example: redirecting the default gateway to a host on the VPN
   4
   5 It is possible to have one node forward all of its network traffic to a host on the VPN,
   6 effectively using this VPN host as the default gateway.
   7 In OpenVPN, there is the `--redirect-gateway` option that does this for a client.
   8 With tinc, there is no such option, but the behaviour can be replicated with a host-up and host-down script.
   9 First there is an explaination of the theory behind redirecting the default gateway,
  10 then example scripts will follow.
  11
  12 ### Theory
  13
  14 Normally, there are two entries in the routing table.
  15 One is the route for the local network,
  16 which tells the kernel which IP addresses are directly reachable.
  17 The second is the "default gateway",
  18 which tells the kernel that in order to reach the rest of the Internet,
  19 traffic should be sent to the gateway of the local network.
  20 Usually the gateway is a router or firewall device,
  21 and its IPv4 address usually ends in `.1`.
  22 An example output of `route -n` on Linux:
  23
  24         Kernel IP routing table
  25         Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
  26         192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
  27         0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
  28
  29 Here, the LAN has the IPv4 address range 192.168.1.0/24, and the gateway is 192.168.1.1.
  30 Suppose we have a VPN with address range 172.16.0.0/16, on which a server exists with address 172.16.1.1.
  31 If we have a VPN connection, and the client wants to replace the standard default route with a default route pointing to 172.16.1.1,
  32 then there is a problem: the kernel does not know anymore how to send the encapsulated VPN packets to the server anymore.
  33 So we need to add an exception for traffic to the real IP address of the VPN server.
  34 Suppose its real address is 192.0.32.10, then the routing table should become:
  35
  36         Kernel IP routing table
  37         Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
  38         172.16.1.1      0.0.0.0         255.255.255.255 UH    0      0        0 vpn
  39         192.0.32.10     192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
  40         192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
  41         0.0.0.0         172.16.1.1      0.0.0.0         UG    0      0        0 vpn
  42
  43 This will ensure the local LAN is reachable, that the VPN server's real IP address is reachable via the original gateway,
  44 that the VPN server's VPN IP address is reachable on the vpn interface,
  45 and that all other traffic goes via the server on the VPN.
  46
  47 It is better not to remove the original default gateway route,
  48 since someone might kill the `tincd` process, such that it doesn't get a chance to restore the original.
  49 Instead, we use a trick where we add two /1 routes instead of one /0 route:
  50
  51         Kernel IP routing table
  52         Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
  53         172.16.1.1      0.0.0.0         255.255.255.255 UH    0      0        0 vpn
  54         192.0.32.10     192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
  55         192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
  56         128.0.0.0       172.16.1.1      128.0.0.0       UG    0      0        0 vpn
  57         0.0.0.0         172.16.1.1      128.0.0.0       UG    0      0        0 vpn
  58         0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
  59
  60 Since both /1 cover all possible addresses, the real default route will never be used while the two /1 routes are present.
  61
  62 ### Scripts
  63
  64 Lets assume we have two nodes called `client` and `server`, and the netname is `myvpn`.
  65 Also, we assume the server has been properly configured to perform routing or masquerading between the VPN and the Internet for the clients that will use it as their default gateway.
  66 Then, only two scripts are necessary on the client.
  67 The following scripts are Linux specific:
  68
  69 `/etc/tinc/myvpn/hosts/server-up`:
  70
  71         #!/bin/sh
  72         VPN_GATEWAY=172.16.1.1
  73         ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
  74
  75         ip route add $REMOTEADDRESS $ORIGINAL_GATEWAY
  76         ip route add $VPN_GATEWAY dev $INTERFACE
  77         ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
  78         ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
  79
  80 `/etc/tinc/myvpn/hosts/server-down`:
  81
  82         #!/bin/sh
  83         ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
  84
  85         ip route del $REMOTEADDRESS $ORIGINAL_GATEWAY
  86         ip route del $VPN_GATEWAY dev $INTERFACE
  87         ip route del 0.0.0.0/1 dev $INTERFACE
  88         ip route del 128.0.0.0/1 dev $INTERFACE
  89
  90 These script use the iproute2 commands, because they are easier to work with.
  91 The `VPN_GATEWAY` variable has to be filled in by hand.
  92 The `ORIGINAL_GATEWAY` variable copies the relevant information from the original default route
  93 to create the exception route to the VPN server.
  94
  95 ### Further configuration
  96
  97 One must also ensure the tinc daemons know which node to send all packets to.
  98 Make sure the following line is in `/etc/tinc/myvpn/hosts/server`:
  99
 100         Subnet = 0.0.0.0/0
 101
 102 Make sure you have masquerading or another form of routing set up on the server.
 103 Do not forget to allow forwarding of packets; check your firewall settings, and
 104 make sure forwarding is enabled in the kernel:
 105
 106         echo 1 >/proc/sys/net/ipv4/ip_forward
 107
 108 You can also set up portforwarding or proxies to be able to connect to services
 109 running on the clients from the rest of the Internet.
 110
 111 ### Router versus switch mode
 112
 113 The examples given above will work with both router and switch mode.
 114 However, in router mode, there is actually no such thing as a gateway route.
 115 For example, the following three lines in the tinc-up script:
 116
 117         ip route add $VPN_GATEWAY dev $INTERFACE
 118         ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
 119         ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
 120
 121 Can be replaced with the following two lines without any problem:
 122
 123         ip route add 0.0.0.0/1 dev $INTERFACE
 124         ip route add 128.0.0.0/1 dev $INTERFACE
 125
 126 In fact, one does not have to set the VPN_GATEWAY variable at all.
 127 In switch mode, the gateway routes are necessary.
 128 However, since Subnet statements are ignored in switch mode,
 129 you do not have to add `Subnet = 0.0.0.0/0` to `/etc/tinc/myvpn/hosts/server` in that case.