Strictly speaking, Kerberos is an authentication system. As a side effect, it exchanges one time secret keys that can be used to encrypt communications. It was designed to provide security in an open, hostile environment, like a University campus. Unfortunately, this makes it "allergic" to firewalls, NAT, split DNS, and many other security techniques that most everyone uses.
Heimdahl is a European reverse engineering of Kerberos (to get around the US crypto restrictions) that addresses some of these issues.
A number of applications like telnet, ftp, rsh and friends, and popper have been kerberized. Also Socks may be compiled with Kerberos.
SASL - new security layer (like gssapi) see www.cyrus.com (cyris?) AFS - new PD version ARLA
Secure Shell uses public key cryptography to provide rsh, rcp, and rlogin services over encrypted channels. It does not send passwords across the net in the clear, even when it has to fall back to rsh. It can also be used to forward X11 and arbitrary ports. This version of ssh can be compiled with socks to traverse firewalls.
Openssh is a re-implementation of ssh to, among other things, avoid certain annoyances with the licensing of version 2. It comes from the OpenBSD project, and uses OpenSSL to provide the encryption code. Since the project is based in Canada, it also avoids the US encryption nonsense.
This solution is a classic example of the UNIX way of doing things, take two existing tools, a couple of scripts, and solve a new problem!
Secure Shell, besides being a secure replacement for the Berkeley r-commands, can also tunnel X and other protocols through it's encrypted connection. In this case, the protocol we choose is PPP. We can now setup a point-to-point link between any two hosts on the Internet, and since PPP presents a network interface at both ends, you can do all the normal routing and firewalling, just as if you had a leased line between the two hosts.
The downside with this method is that when packets get lost, the whole link can pause while they are re-transmitted and the connection re-synced. Other methods that encrypt at the packet level or tunnel over UDP handle packet loss more gracefully. Another problem is that you need to monitor the link and restart it if it fails.
# This is ssh server systemwide configuration file. Port 22 ListenAddress 0.0.0.0 HostKey /etc/ssh_host_key RandomSeed /etc/ssh_random_seed ServerKeyBits 768 LoginGraceTime 600 KeyRegenerationInterval 3600 PermitRootLogin no IgnoreRhosts yes StrictModes yes QuietMode no X11Forwarding yes X11DisplayOffset 10 FascistLogging yes PrintMotd yes KeepAlive yes SyslogFacility DAEMON RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes PasswordAuthentication no PermitEmptyPasswords no UseLogin no
vpn ALL=NOPASSWD: /usr/sbin/pppdto the /etc/sudoers file on the slave.
slave.host.name 192.168.50.1:192.168.50.2Where slave.host.name is the slave's Internet name and the address pair is the addresses to use for the PPP link.
The only thing left is to add any routing command to the file /etc/ppp/ip-up or /etc/ppp/ip-up.local on either end.
or get vpnstarter, a daemon for keeping an SSH-PPP tunnel up, or, if you're using a ppp version greater than 2.3.7, try something like
/usr/sbin/pppd pty 'ssh somehost sudo /usr/sbin/pppd nodetach'
A lightweight protocol that tunnels encrypted IP packets in UDP packets. It has the look and feel of pppd. It has good docs, too bad it doesn't work.
First, you could tunnel this through to an internal NT box and ignore it. Better, IMHO is to use PopTop, a linux pptp server. You do need to patch PPP (and re-compile the kernel) to enable MPPE, but the debugging available make it easier to deal with the broken-ass Microsoft PPTP clients.
The pptp server handles the initial handshake, sets up a GRE tunnel, and then run ppp. If you are using ppp for other things, you may need to differentiate these connections. One trick is:
You include "ipparam pptp" in the options that pptp uses when in runs pppd. Then in ip-up.local, you check the value of $6 (IIRC). You skip the action if $6 is pptp, as it will be, if this is a pptp link coming up.
Microsoft has yet to release a versions of windows without a totally bolloxed up vpn. Follow these links, or try a search for VPN or DUN on the Microsoft site, and install the patches (I had to install the '95 patch twice for it to take)! Once this is done, look at the install docs for Win 98 NT 4 Win 2k and follow the instructions for your particular flavor of windows.
You will probably want to turn off the default gateway. If you don't, then all traffic will be sent through the VPN. Unless your corporate security policy requires this, you can get better performance and fewer problems with this off. Right click on the icon for the connection, and go to Properties->TCP/IP Properties->Advanced and uncheck "Use default gateway on remote network"
You may also need to set the connection specific dns suffix in the same place.
I think that Outlook caches IP addresses when it starts up, so you should re-start outlook when you bring the VPN up or down so it can refresh any addresses that change when you are talking to the internal DNS servers.
You may also need to turn off IP header compression, somewhere in the bowels of the VPN config screens.
For linux, this means FreeSwan, or, if you live in the real world and actually want it to interoperate with other software Super-FreeSwan. This contains a pile of patches, but does tend to lag FreeSwan, sometimes quite a bit. It is Grand-Central station for finding patches to improve FreeSwan. The most important ones are are the X.509 patch for talking to Windows boxes, NAT-T for tunneling IPSEC over udp, the ALG patch for extra algorithms, ...
www.securityfocus.com -> other lists -> vpn mailing list www.icsa.net -> ipsec - compatibility testing results for vendors, maybe free OS soon.