[Vtun-Users] FAQ section on routing and security

[Jim C. <ji...@ma...>]

Here's a section on routing and security that might be added to the FAQ.
Note the "manually substitute" clauses -- it would be really helpful if the
daemon could figure these out itself.  The script I mentioned in my
previous posting (http://www.math.ucla.edu/~jimc/jvtun) handles these
substitutions.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: ji...@ma...  http://www.math.ucla.edu/~jimc (q.v. for PGP key)


3.  Routing

3.1 Why does vtun always freeze up as soon as I put on my routes?

You establish the tunnel as a tcp/ip connection to the server.  If you
route to the server's net (e.g. your default route) through the tunnel,
then the tunnel packets have to go through the tunnel.  Choke.  See the
next item.

3.2 What's a good set of routes to put on, then?

These use Linux syntax, and you have to manually replace %A with the
prearranged IP address of the local tunnel/tap device, and %a with
the remote one.  Don't use the public IP addresses of the client and
server; it will lock up the communication instantly.  Manually substitute
%D with the gateway of the default route, and %h with the public IP
address of the server.  vtund replaces %d (or %%) with the device name.

    up {
	ifconfig "%d %A pointopoint %a netmask 255.255.255.255 mtu 1450";
	route "add -host %h gw %D";
	route "add default gw %a metric 0";
	route "del default gw %D";
	route "add default gw %D metric 10";
    };
    down {
	route "del -host %h gw %D";
	ifconfig "%d down";
    };

The host route to the server through the real gateway ensures that
tunnel packets go there, not down the tunnel.  The reason for the
"metric 10" stuff is so the default route through the tunnel will be
preferred and actually used.  If both default routes have metric 0, it's
implementation defined which is used, and on my system it's not
the tunnel.  You don't need this unless you actually put the default
route through the tunnel.

3.3 I can connect to my department but not to any others.  --Or--
With the default route through the tunnel, I can't connect to anything.

Your packets originate from the IP address of your local tunnel/tap
device, and the answers go back to that IP.  If your department's
default route is through the machine with the vtun server, it has a
chance to grab the packets.  But nobody else knows where to send them.
The vtun server has to do Network Address Translation (NAT), so all the
packets will seem to originate from it and will come back to it.  On a
bastion host with only one interface (here, eth0) you can convince your
sysop to add this to its firewall rules (Linux iptables):

    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

On a router you have to restrict it by source address; you don't want to
do NAT on regular packets unless it's a home gateway.  Suppose you can
guarantee that the client's tunnel device IP address is in
172.16.251.0/24.  Then:

    iptables -t nat -A POSTROUTING -s 172.16.251.0/24 -j MASQUERADE

3.4  My home gateway can connect, but not my other machines.

For security it's best if the originating machine runs vtun, but this
may not be possible until there is a Windows client, and you may have to
run vtun on the Linux gateway.  You are probably already doing NAT for
sharing your DSL or cable; you need to also do it on packets going down
the tunnel.  The server has no idea to route your 192.168.0.x home
packets to your tunnel (and not to someone else's) unless they are
masqueraded to appear to come from the home gateway.  It won't hurt to
do NAT twice, on your gateway and on the vtun server.

3.5  Traceroute and/or ping don't work through the tunnel.

The server may not be doing NAT on the ICMP packets, or may have them
blocked as a security precaution.

4 Security Issues

4.1  The black hats stole my password!  Doesn't vtun encrypt?

You do need to turn that on.  But also, your traffic is protected only
on the hop from the client to the server.  From there to the ultimate
destination, someone can snoop your packets.  Also at your end, if you
have vtun on your home gateway and a wireless link to your laptop,
people in black helicopters can use AirSnort to crack your wireless
(assuming you turned on WEP in the first place).  A major weakness
of a VPN is that the black hats can attack the endpoints.  You should
be running vtun on the laptop -- like I do.

4.2  A virus came through the tunnel.  Gaping security hole?

Right on.  If you let people connect via any VPN solution, every virus
in their homes is going to start chewing on your soft underbelly.  Of
course a machine in your department can also get virused out if someone
clicks on an attachment by accident.  So every potential victim machine
should be up to date on patches, and should have as strong a firewall as
possible consistent with getting its work done.  It's bad policy to
allow insecure protocols, particularly Windows services and file
sharing, over a VPN to home machines, and the best policy is to trust a
VPN client as if coming from the global Internet, i.e. not at all.  By
using the VPN you keep people from snooping your traffic, but you invite
unwelcome visitors from poorly maintained home machines.  Similarly,
virus packets reaching the server can in some configurations be routed
to the client.

4.3  What good is a VPN if you must guard against hackers on the tunnel?

The VPN keeps secrets from getting out.  End-to-end fourth layer
protocols like ssh are best, since spying is possible only on the very
machines at the endpoints, but not every service has an encrypted
variant, and for these the VPN serves as generic encryption.  Some
wireless network operators route only intrinsically encrypted ports and
protocols, and on these you must set your default route down a VPN
tunnel, even for ports like WWW where there is no expectation of
privacy.  Some services use host-based authentication, and will serve
the VPN endpoint (and clients appearing by NAT to come from it) which
they would not do for the clients (or viruses) at their home addresses.