[Vtun-Users] FAQ section on routing and security
Status: Inactive
Brought to you by:
mtbishop
|
From: Jim C. <ji...@ma...> - 2003-08-12 04:47:18
|
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. |