Update redirect-gateway example.

- Correct some mistakes in the example output of "route -n".
- One must add a route to a gateway before one can add gateway routes.
- Make it more clear one must also set up masquerading or other ways of routing
  on the server, enable forwarding, and possibly modify firewall rules.
- Add a note about the effect of router and switch mode on redirecting ther
  gateway.

diff --git a/examples/redirect-gateway.mdwn b/examples/redirect-gateway.mdwn
index 180d572..a6b2001 100644 (file)
--- a/examples/redirect-gateway.mdwn
+++ b/examples/redirect-gateway.mdwn
@@ -23,7 +23,7 @@ An example output of `route -n` on Linux:
 
        Kernel IP routing table
        Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
-       192.168.1.42    0.0.0.0         255.255.255.0   U     0      0        0 eth0
+       192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
        0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
 
 Here, the LAN has the IPv4 address range 192.168.1.0/24, and the gateway is 192.168.1.1.
@@ -35,11 +35,13 @@ Suppose its real address is 192.0.32.10, then the routing table should become:
 
        Kernel IP routing table
        Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
+       172.16.1.1      0.0.0.0         255.255.255.255 UH    0      0        0 vpn
        192.0.32.10     192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
-       192.168.1.42    0.0.0.0         255.255.255.0   U     0      0        0 eth0
-       0.0.0.0         192.0.32.10     0.0.0.0         UG    0      0        0 vpn
+       192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
+       0.0.0.0         172.16.1.1      0.0.0.0         UG    0      0        0 vpn
 
 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.
 
 It is better not to remove the original default gateway route,
@@ -48,10 +50,11 @@ Instead, we use a trick where we add two /1 routes instead of one /0 route:
 
        Kernel IP routing table
        Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
+       172.16.1.1      0.0.0.0         255.255.255.255 UH    0      0        0 vpn
        192.0.32.10     192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
-       192.168.1.42    0.0.0.0         255.255.255.0   U     0      0        0 eth0
-       128.0.0.0       192.0.32.10     128.0.0.0       UG    0      0        0 vpn
-       0.0.0.0         192.0.32.10     128.0.0.0       UG    0      0        0 vpn
+       192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
+       128.0.0.0       172.16.1.1      128.0.0.0       UG    0      0        0 vpn
+       0.0.0.0         172.16.1.1      128.0.0.0       UG    0      0        0 vpn
        0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
 
 Since both /1 cover all possible addresses, the real default route will never be used while the two /1 routes are present.
@@ -66,10 +69,11 @@ The following scripts are Linux specific:
 `/etc/tinc/myvpn/hosts/server-up`:
 
        #!/bin/sh
-       VPN_GATEWAY=192.168.1.1
+       VPN_GATEWAY=172.16.1.1
        ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
 
        ip route add $REMOTEADDRESS $ORIGINAL_GATEWAY
+       ip route add $VPN_GATEWAY dev $INTERFACE
        ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
        ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
 
@@ -79,6 +83,7 @@ The following scripts are Linux specific:
        ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
 
        ip route del $REMOTEADDRESS $ORIGINAL_GATEWAY
+       ip route del $VPN_GATEWAY dev $INTERFACE
        ip route del 0.0.0.0/1 dev $INTERFACE
        ip route del 128.0.0.0/1 dev $INTERFACE
 
@@ -89,7 +94,36 @@ to create the exception route to the VPN server.
 
 ### Further configuration
 
-The only thing left is to ensure the tinc daemons know which node to send all packets to.
+One must also ensure the tinc daemons know which node to send all packets to.
 Make sure the following line is in `/etc/tinc/myvpn/hosts/server`:
 
        Subnet = 0.0.0.0/0
+
+Make sure you have masquerading or another form of routing set up on the server.
+Do not forget to allow forwarding of packets; check your firewall settings, and
+make sure forwarding is enabled in the kernel:
+
+       echo 1 >/proc/sys/net/ipv4/ip_forward
+
+You can also set up portforwarding or proxies to be able to connect to services
+running on the clients from the rest of the Internet.
+
+### Router versus switch mode
+
+The examples given above will work with both router and switch mode.
+However, in router mode, there is actually no such thing as a gateway route.
+For example, the following three lines in the tinc-up script:
+
+       ip route add $VPN_GATEWAY dev $INTERFACE
+       ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
+       ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
+
+Can be replaced with the following two lines without any problem:
+
+       ip route add 0.0.0.0/1 dev $INTERFACE
+       ip route add 128.0.0.0/1 dev $INTERFACE
+
+In fact, one does not have to set the VPN_GATEWAY variable at all.
+In switch mode, the gateway routes are necessary.
+However, since Subnet statements are ignored in switch mode,
+you do not have to add `Subnet = 0.0.0.0/0` to `/etc/tinc/myvpn/hosts/server` in that case.