Remote Gateway
|
2/10/2005 Functions: Each user has a login account on gateway and corresponding login account on home network network server.. When a user logs onto gateway, Netware drives are mapped, using same username/initials on netware server as on gateway, under user's home directory on gateway. Drive letters are then mapped on user's local computer to these directories on gateway. Specified IPX traffic is bridged over VPN Gateway is also gateway for IP traffic. Provides DHCP server (handing out private subnet addresses), DNS server, and firewall. IP traffic does NOT go through VPN, unless destination is on home intranet. Allows remote administration only through "knock and open" method, under SSH. Local administration function to create users? ============================================================= IPSec is used to establish VPN. This consists of AH (IP protocol 51) and ESP (IP Protocol 50). IKE protocol is used to exchange keys, over UDP port 500. Use NAT to encapsulate ESP in UDP packets, over port 4500. SCTP? QOS? =================== First, get current by using Yum: rpm --import http://www.fedora.us/FEDORA-GPG-KEY vi /etc/yum.repos.d/fedora.repo vi /etc/yum.repos.d/fedora-updates.repo
Add the following to /etc/yum.repos.d/crash-hat.repo: =================== Upgrade OpenSSL: tar -xvzf openssl-0.9.7e.tar.gz Note that I did not even uninstall the RPM first; I simply overwrote
the files in it. That's what the --prefix=/ was for! rm /lib/libssl.so.0.9.7a rm /lib/libcrypto.so.0.9.7a These last two linking steps are extremely important in order to remove the old version, yet still make everything work. =================== OpenSSH: rpm -e openssh-server tar -xvzf openssh-3.9p1.tar.gz As usual, I got the following error when running ./configure: I had already gone through the process of uninstalling and reinstalling zlib, so this time I looked around a little more and found out that I needed zlib-devel installed so that it could find the headers. I did that, ran the ./configure --prefix=/usr --without-PAM step again, and no longer got that particular error. I did, however, get the following error: configure: error: OpenSSL version header not found. I downloaded the openssl-devel rpm, version 0.9.7e, which matched the version of the openssl .tar.gz that I had installed. I had to install openssl-devel with the --nodeps option, since rpm still thought I had version 0.9.7a, but it installed just fine. I ran ./configure --prefix=/usr --without-PAM in OpenSSH once again, and this time did not get that particular error. In fact, it ran without a hitch. Thus, I ran make and then make install and finished the installation. Because the tarball version of OpenSSH does not install a startup script, I copied one of my own into the /etc/rc.d/init.d/ directory. I then made a symbolic link, S55sshd, in both the /etc/rc.d/rc3.d/ and /etc/rc.d/rc5.d/ directories (by typing ln -sv /etc/rc.d/init.d/sshd /etc/rc.d/rc3.d/S55sshd). Finally, I copied my own, more secure version of the sshd_config file to /usr/etc/sshd_config. The most important parts of this file, I believe, arethat everyone is forced to use RSA certificates rather than passwords, and to make SSHD listen on a non-standard port. To verify that SSHD was indeed listening on that non-standard port, I first ran netstat -an. lsof -i will work as well. Sure enough, it was listening, but for some reason it wasn't answering from the outside. In order to make it easier to keep track of keys, I also have a little script called putkeys that sits in the /logins/keys/ directory that I created. The corresponding configuration file, keyconfig, also sits in that directory and has a list of filenames for each user's key underneath the appropriate user that they should be able to log in as. Take a look at the config file, you'll see what I'm talking about. Every time I want to add a user, I copy their key file to /logins/keys/ and then run /logins/keys/putkeys. This CONVERTS EACH PUBLIC KEY FROM PUTTY FORMAT (using the command ssh-keygen -i -f puttyformatkeyfile.pub) and then appends them to the .ssh/authorized_keys file in the appropriate user's home directory.
=================== DHCP
Setting up a DHCP server on this box was incredibly easy. First, I installed the dhcp package. I did this by downloading/extracting the .tar.gz, then ran the following commands from that directory:
I prepared the /etc/rc.d/init.d/dhcpd script to run by creating the dhcp.leases file: touch /var/state/dhcp/dhcp.leases I then edited the /etc/sysconfig/dhcpd file to look like the following:
Yep, that's right. One simple line, since I wanted it to answer on all interface (in actuality, I just want it to answer anything on the bridge), then filter it by interface using ebtables. Next, I modified /etc/dhcpd.conf to look like the following:
I think it's pretty straightforward. The bridge, of course, is given an alias IP address of 192.168.5.1, which matches the IP in that "option routers" line. This is down by running the command ifconfig jbridge:0 192.168.5.1, which I added to my bridge startup script right before I actually put the bridge up. I put my own modified dhcpd script in /etc/rc.d/init.d. I then ran it by typing /etc/rc.d/init.d/dhcpd start. Everything loaded great. I could see it by typing ps aux | grep dhcp. Finally, of course I added links in the /etc/rc.d/rc3.d and rc5.d directories so that it would be started with the server. Just that simple! =================== IPSec Tools: First, I set up all my certificates as described in my Creating a Certificate Authority journal entry. Next, I set up my security policies. Racoon will set up the actual security associations on the fly. Security Policies are configured in the file /etc/setkey.conf, then loaded by running setkey -f /etc/setkey.conf. Setkey, of course, is part of ipsec-tools. My /etc/setkey.conf file looks similar to the following: To display the SPD (Security Policies Database), type setkey -DP. If your security policies are configured, at least for local communication to your destination, when you try to ping that destination, it will say Connect: No such process even though you can successfully ping anything outside of that destination(s).
Now, I set up racoon to create the Security Associations. Racoon lets us establish IPSec connections without having pre-defined (and static) keys, in our case using Kerberos to initiate a connection and then generating keys on-the-fly. The configuration for racoon is stored in /etc/racoon/racoon.conf. To learn more about what you can put in this file, type man racoon.conf. Start racoon to automatically handle the security associations. To do this, type racoon -F -f /etc/racoon.conf. The -F flag forces racoon to run in the foreground, for debugging purposes. Remove this flag to run as a daemon.
When I first tried starting racoon on both computers and pinging one from the other, I repeatedly got the following message:
Racoon would continue to try to establish the phase 1 connection, but nothing was successful. While that phase 1 connection was queued, it would also try to establish the phase 2 connection, which would simply time out while waiting for phase 1. I realized, however, that I hadn't ensured that I had a connection without IPSec. I added the appropriate ARP entries, and now I could ping back and forth before I had the Security Policies in place.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ To display the SAD (Security Associations Database), type setkey -D.
Once I finally thought I had /etc/racoon/racoon-tool.conf set
correctly, I tried starting racoon-tool by typing racoon-tool.pl
start, only to get the following error:
I looked through the racoon-tool.pl script, and discovered that
racoon.conf must already exist before racoon-tool.pl is run -
it does not generate a file completely from scratch. I created an empty
file, then ran the script again, this time getting the following error:
After playing around with racoon-tool.pl for a while, I came to the realization that it simply didn't do what I thought it would. I had decided to use it simply because I wanted to run IPSec on a client with a dynamic IP. Unfortunately, when you're specifying tunnel mode, racoon-tool makes you specify the source ip as well. What racoon-tool does do is handle all the nitty-gritty crap for you. For instance, not only will it load racoon with a custom-built racoon.conf on-the-fly, but it will handle setting all your security associations and policies by running setkey as well. It will save you a lot of confusing work, but I like to have more control than that, so I decided to write a simple script to do the stuff for me.
Automatic key exchange using racoon Configuring racoon to the point where you can successfully exchange keys is reasonably easy. The default racoon.conf file is sufficient for a basic setup. However, we would recommend that the following items be changed. The default log level of "debug4" is very chatty. While its handy when setting things up normally, its a bit excessive for normal usage. To reduce logging, change the line log "debug4"; to log "info"; In a thread on the freebsd-net mailing list, it was pointed out that the default values for the lifetime of the keys negotiated by racoon is far too short for WAN links, especially over PPPoE links. Thus, you may want to give thought to changing the 'lifetime time' and 'lifetime byte' parameters in the 'sainfo anonymous' stanza to 3600 seconds and 50000 kb respectively.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ========= IPX tunneling I needed to tunnel IPX traffic from our local network to the remote site. First, I turned on the following kernel options on both ends of the tunnel:
Now, here is how the whole routing thing works, with just one linux box between the workstation and the server:
Next, I installed ipxrip. I could not get this to compile on my Fedora Core 3 box, so I downloaded the SuSE rpm and installed it with the --nodeps option. I created a startup script called ipx and added this daemon to the beginning, by simply running the command /usr/sbin/ipxd. This is what it does:
I tried three different daemons for turning IPX into IP and tunneling it. The first, ipxtunnel, which was talked about in the IPX HOWTO, looked very promising, but seriously ate up the CPU. No good. Next, I tried tipxd, which also looked promising, but I spent a while trying to get it to work, and for some reason I could never get the two sides to communicate. I'm sure I could have gotten it if I had fooled around a while longer, but it wasn't worth it to me. I moved on to ipxtund. |
| Downloads: |
| sshd |  |
SSHD startup script, goes in /etc/rc.d/init.d/ directory. |
| sshd_config | My SSHD configuration file, /usr/etc/sshd_config | |
| putkeys | my /logins/keys/putkeys script to put users' RSA keys in the appropriate places. | |
| keyconfig | /logins/keys/keyconfig configuration file for my putkeys script. | |