By Kurt Seifried [email protected]

Introduction

There are a variety of VPN solutions for Linux. I would strongly advise using IPSec if possible since it is the emerging standard for VPN's on the Internet, and will be incorporated with IPv6. On the other hand if you are behind a firewall and want to tunnel out the SSH based solution and so on will do the trick, whereas IPSec will typically fail (since the packet headers are being rewritten).

OpenVPN

https://www.openvpn.org/

OpenVPN is a high quality VPN based on OpenSSL. It has nearly as many features as IPSec and is much more easy to setup and deploy. Since VPNs are used, by its own nature, in non public deployments I don't think the standarization of IPSec is a determinant factor. And of course since IPSec is more complex and usually implemented at the "kernel" level it is potentially less secure than OpenVPN that works as a normal daemon in user space (with moderm virtual machines technologies like Xen that must not be true actually but I didn't have the time to check how IPSec of OpenVPN work in such environments.)

There is just an implementation of OpenVPN vs. tens of different implementations of IPSec. That means that OpenVPN will never have incompatibility problems but also that you are stuck with a single implementation (at this moment, July of 2005, the existing implementation is really good and so is support for load balancing, failover, and fine-grained access-controls.)

OpenVPN uses standard UDP connections (there are really good reasons to use UDP and not TCP for VPNs) and so is also firewall friendly. Of course being based on OpenSSL provides it with perfect support for public certificates.

Well supported versions exist for Linux 32/64 bit and other "Unix flavors" as well as for Windows. It also integrates really well with existing Linux network tools (ip, iptables, netstat, bandwith management, ...)

In my own experience OpenVPN plays nice with Streaming/RealTime/VoIP data (PPTP and CIPE are painful in this area with low-quality WAN connections and ssh just doesn't work with UDP.) It's quite simple to install it in a server and run two different instances with two different sets of parameters to establish parallel data and streaming VPNs with suitable MTU for each one.

The support via mailing list is also really good and really alive (https://sourceforge.net/mailarchive/forum.php?forum_id=8453) and the documentation is good and ordered with examples and useful, wellthought scripts to generate the private/public keys.

PPTP (Point to Point Tunneling Protocol)

PPTP is a proprietary protocol created by Microsoft for VPN solutions. To date it has been shown to contain numerous serious flaws. However if you need to integrate Linux into a PPTP environment all is not lost, https://www.moretonbay.com/vpn/pptp.html contains a Linux implementation of PPTP.Fortunately Microsoft is moving away from PPTP towards IPSec.

CIPE (Crypto IP Encapsulation)

CIPE is a free IP level encryption scheme, meant for use between routers. It is appropriate for 'bridging' networks securely together over insecure networks (like the Internet). The official cite for CIPE is at: https://sites.inka.de/~W1011/devel/cipe.html. I would however recommend FreeS/WAN as a better long term solution. CIPE is very easy to setup for two servers but anything more then two servers becomes a configuration nightmare.

Zebedee

Zebedee provides encryption of TCP traffic between hosts and is available for UNIX and windows. You can get it from: https://www.winton.org.uk/zebedee/.

IP Security (IPSec)

IP Security (IPSec) is the encryption of network traffic. You cannot encrypt the header information or trailer (i.e. the IP address/port the packet is from, and going to, the CRC checksums, and so on), but you can encrypt the data payload. This allows you to secure protocols such as POP/WWW without having to change them in any ways, since the encryption occurs at the IP level. It also allows you to securely connects LANs and clients to each other over insecure networks (like the Internet). Currently IPSec for Linux is in testing, however there have been several stable releases, and I myself have deployed Linux based IPSec servers successfully. IPSec is a standard, and a part of the IPv6 protocol, you can already purchase IPSec software for Windows 95/98/NT, Solaris, and other unices that will interoperate with Linux IPSec. For "drilling" through a firewall or perhaps to get by a NAT box (such as Linux with IP Masquerading) please see the Linux Firewalling Overview.

FreeSWAN is a free, OpenSource IPSec implementation for Linux. It's a pretty solid implementation however not as advanced as some, automatic keying and certificate support is well under way though, and should be "production" quality relatively soon.

IP Security (IPSec) is the encryption of network traffic. You cannot encrypt the header information or trailer (i.e. the IP address/port the packet is from, and going to, the CRC checksums, and so on), but you can encrypt the data payload. This allows you to secure protocols such as POP/WWW without having to change them in any ways, since the encryption occurs at the IP level. It also allows you to securely connects LANs and clients to each other over insecure networks (like the Internet). Currently IPSec for Linux is in testing, however there have been several stable releases, and I myself have deployed Linux based IPSec servers successfully. IPSec is a standard, and a part of the IPv6 protocol, you can already purchase IPSec software for Windows 95/98/NT, Solaris, and other Unices that will interoperate with Linux IPSec. For "drilling" through a firewall or perhaps to get by a NAT box (such as Linux with IP Masquerading) please see the firewall section.

You will need to compile support into your kernel, this is a somewhat tricky process, but if you follow the instructions included it should go smoothly. The primary difficulty is usually setting up the configuration file, you will definitely want to read the IPSec documentation for this as it changes (especially when support for new features is added).

[1]

IPSec kernel support

To use IPSec you need IPSec support in the kernel. Unfortunately no American Linux distribution can ship strong crypto outside of North America so generally speaking they choose not to include it at all, of the foreign Linux distributions, currently, none ship with IPSec support built into the kernel. You will need to get the kernel source (I recommend 2.2.13, as of December 1999), and the Linux IPSec source code, available from: https://www.freeswan.org/ (current stable snapshot 1.2, as of December 1999).

Install the kernel source (usually to /usr/src/linux) and then compile a new kernel, install it, boot to it, and test it. Make sure your networks work properly, if they don't work, getting IPSec to work will be impossible. Now you need to download the latest IPSec software (version 1.0 will NOT work with 2.2.x kernels). Then go to /usr/local/src (or wherever you put your source code for programs), unpack the source and run the install program (make menugo typically for the ncurses based configuration). This will patch the kernel files, then run the kernel configuration, and then build the IPSec tools, and the kernel.

cd /usr/local/src/
tar -zvvxf /path/to/tarball/snapshot.tar.gz
chown -R root:root freeswan-snap1999Jun14b
cd freeswan-snap1999Jun14b
make menugo

make sure you save the kernel configuration, even though the options are chosen they have not been saved. You might also have to rebuild the kernel as the "make menugo" command sometimes runs a "make zImage" which usually fails due to the large kernel sizes with 2.2.x. Once the compile is done it should have an error message or two, simply:

cd /usr/src/linux
make bzImage
cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.2.13-ipsec

Now we need to edit lilo.conf, rerun lilo, and reboot to make use of the new kernel. lilo.conf should look like:

boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=100
image=/boot/vmlinuz-2.2.13-ipsec
label=linux-ipsec
root=/dev/hda1
read-only
image=/boot/vmlinuz-2.2.13
label=linux
root=/dev/hda1
read-only

rerun lilo and you should see:

linux-ipsec *
linux

then reboot and you should be running kernel 2.2.13 with IPSec support. As the machine reboots and starts the IPSec stuff you will see several errors, by default IPSec is set to use the eth999 interface, which of course does not exist. You should also add /usr/local/lib/ipsec to your path statement or else you will have to type the full path in a lot.

IPSec network setup

You will need to enable TCP-IP forwarding on the gateway server, in Red Hat Linux this is accomplished by changing the line in /etc/sysconfig/network from:

FORWARD_IPV4="false"

to:

FORWARD_IPV4="yes"

or you can enable it via the /proc filesystem:

cat 1 > /proc/sys/net/ipv4/ip_forward

Since most people have default deny policies for forwarding packets you will need to allow packets to traverse from the remote network / machine to your network / machine and vice versa. In addition to this, any masquerading rules for internal networks that are also using IPSec must come after the rules allowing IPSec related traffic, or the machine will try to masquerade the packets, instead of them being passed over to IPSec.

IPSec configuration

Then you need to configure your ipsec settings. These are typically held in /etc/ipsec.conf, and /etc/ipsec.secrets, you can use an include statement however to break the files up.

Manual connection keying

First we'll set up a link using manual keying (for simplicity), you will need to edit ipsec.conf, and your firewall rules. Most of the defaults in the ipsec.conf file are fine but you will need to change the following:

conn sample
type=tunnel
left=
leftnexthop=
leftsubnet=
right=
rightnexthop=
rightsubnet=
spibase=0x200
esp=3des-md5-96
espenckey=
espauthkey=

replace the espenckey and espauthkey with new keys (using ranbits to generate a number, remember to leave the leading 0x that specifies it is a hex number) so that it looks like:

conn my-tunnel
type=tunnel
left=1.2.3.4
leftnexthop=1.2.3.1
leftsubnet=10.0.0.0/24
right=5.6.7.8
rightnexthop=5.6.7.1
rightsubnet=192.168.0.0/24
spibase=0x200
esp=3des-md5-96
espenckey=some_auth_key_here (ranbits 192)
espauthkey=some_other_key_here (ranbits 128)

Once you have done this copy the files ipsec.conf and ipsec.secrets from the machine you edited them on to the other server in a secure manner. Now all that remains to be done is the addition of some firewall rules so that packets do not get masqueraded (instead we simply want them forwarded).

On Server 1.2.3.4 you should add the following rules:

ipchains -A forward -p all -j ACCEPT -s 10.0.0.0/24 -d 192.168.0.0/24
ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d 10.0.0.0/24

make sure these rules appear before the masquerading rule, it should look like this:

#
# FORWARD RULES
#
ipchains -P forward DENY
#
ipchains -A forward -p all -j ACCEPT -s 10.0.0.0/24 -d 192.168.0.0/24
ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d 10.0.0.0/24
ipchains -A forward -p all -j MASQ -s 10.0.0.0/24 -d 0.0.0.0/0

And on server 5.6.7.8 you basically repeat the process:

ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d 10.0.0.0/24
ipchains -A forward -p all -j ACCEPT -s 10.0.0.0/24 -d 192.168.0.0/24

make sure these rules appear before the masquerading rule, it should look like this:

#
# FORWARD RULES
#
ipchains -P forward DENY
#
ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d 10.0.0.0/24
ipchains -A forward -p all -j ACCEPT -s 10.0.0.0/24 -d 192.168.0.0/24
ipchains -A forward -p all -j MASQ -s 192.168.0.0/24 -d 0.0.0.0/0

Now you should be able to bring up the ipsec tunnel on both machines manually and the machines on Network A should be able to talk to the machines on Network B with no problems.

ipsec manual -up my-tunnel

and it should produce output similar to:

/usr/local/lib/ipsec/spi: message size is 36
/usr/local/lib/ipsec/spi: message size is 132
/usr/local/lib/ipsec/spi: message size is 132

To test it try pinging 192.168.0.2 from the 10.0.0.2 client. If this works then you have set it up correctly. If it does not work check your network to make sure 1.2.3.4 can reach 5.6.7.8, and that TCP-IP forwarding is enabled, and make sure that no firewall rules are blocking the packets, or trying to masquerade them. Once you have established a connection and tested it successfully you should move to automatic keying (especially if it's in a production environment).

Automatic connection keying

If you intend to use IPSec in a production environment, manual keying is a bad idea generally speaking. With automatic keying you have a 256 bit shared secret you copy to both ends of the tunnel, which is then used during the key exchanges to make sure a man in the middle attack does not occur. With automatic keying the default lifetime of a key is 8 hours, which you can set to anything you like, and if someone manages to brute force the key, it is only good for that 8 hour chunk of traffic. The following example builds on the previous one:

ipsec.secrets contains the shared secret. This file must be kept secure at all costs. For a connection between the 1.2.3.4 and 5.6.7.8 servers you would need a line like:

1.2.3.4 5.6.7.8 "0xa3afb7e6_20f10d66_03760ef1_9019c643_a73c7ce0_91e46e84_ef6281b9_812392bf"

This line needs to be in the ipsec.secrets file of both computers. You would then need to edit the tunnel configuration in ipsec.conf to the following:

conn my-tunnel
type=tunnel
left=1.2.3.4
leftnexthop=1.2.3.1
leftsubnet=10.0.0.0/24
right=5.6.7.8
rightnexthop=5.6.7.1
rightsubnet=192.168.0.0/24
keyexchange=ike
keylife=8h
keyingtries=0

The pluto daemon will then startup, try to connect to the Pluto daemon at the other end of the tunnel, and establish a connection. One caveat, Pluto runs on port 500, UDP, so chances are you will have to poke a hole in your firewall to allow it through:

ipchains -A input -p udp -j ACCEPT -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 500

I find it convenient to use the "%search" keyword instead of listing the tunnel to bring up, by adding:

auto=start

to each tunnel configuration and editing ipsec.secrets:

plutoload=%search
plutostart=%search

This will make your life generally easier in the long run. If all goes well you should see something like this in /var/log/messages:

Jun 26 02:10:41 server ipsec_setup: Starting FreeS/WAN IPSEC... 
Jun 26 02:10:41 server ipsec_setup: /usr/local/lib/ipsec/spi: message size is 28. 
Jun 26 02:10:41 server ipsec_setup: KLIPS debug `none' 
Jun 26 02:10:41 server ipsec_setup: KLIPS ipsec0 on eth0 1.2.3.4/255.255.255.0 
     broadcast 24.108.11.255 Jun 26 02:10:42 server ipsec_setup: Disabling core dumps: 
Jun 26 02:10:42 server ipsec_setup: Starting Pluto (debug `none'): 
Jun 26 02:10:43 server ipsec_setup: Loading Pluto database `my-tunnel': 
Jun 26 02:10:44 server ipsec_setup: Enabling Pluto negotiation: 
Jun 26 02:10:44 server ipsec_setup: Routing for Pluto conns `my-tunnel': 
Jun 26 02:10:45 server ipsec_setup: Initiating Pluto tunnel `my-tunnel': 
Jun 26 02:10:45 server ipsec_setup: 102 "my-tunnel" #1: STATE_MAIN_I1: initiate 
Jun 26 02:10:45 server ipsec_setup: 104 "my-tunnel" #1: STATE_MAIN_I2: from STATE_MAIN_I1; 
  sent MI2, expecting MR2 
Jun 26 02:10:45 server ipsec_setup: 106 "my-tunnel" #1: STATE_MAIN_I3: from STATE_MAIN_I2; 
  sent MI3, expecting MR3 
Jun 26 02:10:45 server ipsec_setup: 003 "my-tunnel" #1: STATE_MAIN_I4: SA established 
Jun 26 02:10:45 server ipsec_setup: 110 "my-tunnel" #2: STATE_QUICK_I1: initiate 
Jun 26 02:10:45 server ipsec_setup: 003 "my-tunnel" #2: STATE_QUICK_I2: SA established 
Jun 26 02:10:46 server ipsec_setup: ...FreeS/WAN IPSEC started

And in the /var/log/secure file you should see something like:

Jun 26 02:10:42 server Pluto[25157]: Starting Pluto (FreeS/WAN Version snap1999Jun14b)
Jun 26 02:10:44 server Pluto[25157]: added connection description "my-tunnel"
Jun 26 02:10:44 server Pluto[25157]: listening for IKE messages
Jun 26 02:10:44 server Pluto[25157]: adding interface ipsec0/eth0 1.2.3.4
Jun 26 02:10:44 server Pluto[25157]: loading secrets from "/etc/ipsec.secrets"
Jun 26 02:10:45 server Pluto[25157]: "my-tunnel" #1: initiating Main Mode
Jun 26 02:10:45 server Pluto[25157]: "my-tunnel" #1: ISAKMP SA established
Jun 26 02:10:45 server Pluto[25157]: "grumpy-seifried" #2: initiating Quick Mode 
   POLICY_ENCRYPT+POLICY_TUNNEL+POLICY_PFS
Jun 26 02:10:45 server Pluto[25157]: "my-tunnel" #2: sent QI2, IPsec SA established
Jun 26 02:11:12 server Pluto[25157]: "my-tunnel" #3: responding to Main Mode
Jun 26 02:11:12 server Pluto[25157]: "my-tunnel" #3: sent MR3, ISAKMP SA established
Jun 26 02:11:12 server Pluto[25157]: "my-tunnel" #4: responding to Quick Mode
Jun 26 02:11:12 server Pluto[25157]: "my-tunnel" #4: IPsec SA established
Jun 26 02:31:31 server Pluto[25157]: "my-tunnel" #5: responding to Main Mode
Jun 26 02:31:32 server Pluto[25157]: "my-tunnel" #5: sent MR3, ISAKMP SA established
Jun 26 02:31:32 server Pluto[25157]: "my-tunnel" #6: responding to Quick Mode
Jun 26 02:31:32 server Pluto[25157]: "my-tunnel" #6: IPsec SA established

In addition to this you can view the "eroute" output to make sure the tunnels are correctly configured:

10.0.0.0/24 -> 192.168.0.0/24 => [email protected]

And if you view your routes ("route") you should see:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
1.2.3.4 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
10.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth
11.2.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
1.2.3.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
192.168.0.0 1.2.3.1 255.255.255.0 UG 0 0 0 ipsec0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 
eth1127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 
lo0.0.0.0 1.2.3.1 0.0.0.0 UG 0 0 0 eth0

Some example ipsec configurations

Two servers with protected networks directly attached

In our example we will have the following network setup:

Server A, where eth0 is attached to the Internet and has the IP address 1.2.3.4, and eth1 is attached to the internal network and has the IP address 10.0.0.1.

Network A is the network 'behind' Server A and consists of machines on the 10.0.0.* subnet.

Server B, where eth0 is attached to the Internet and has the IP address 5.6.7.8, and eth1 is attached to the internal network and has the IP address 192.168.0.1.

Network B is the network 'behind' Server B and consists of machines on the 192.168.0.* subnet.

Network C is the Internet, to which Server A and B are connected (by T1, let's be generous).

Basic server setup

Each machine will have Red Hat Linux 6.1 installed, with the default kernel 2.2.12, make sure you install ipchains, by default this does not usually get installed. Any other software on the machines is incidental (we are primarily concerned about moving packets and such).

Go to ftp.linux.org (or your favourite mirror) and download the full Linux kernel 2.2.10. Go to /usr/src/ and remove the existing linux symlink, unpack kernel 2.2.10 and mv it to /usr/src/linux-2.2.10, and recreate the "linux" symlink to point to it. Then cd into /usr/src/linux, configure the kernel, compile and install it. Make sure you choose all the IP masquerading items, and where possible compile them in as static components, and not modules. Remember to use "make bzImage", as chances are the new kernel will be to large for lilo to load normally.

       rm linux

       tar -zvvxf /path/to/tarball/linux-2.2.10.tar.gz

       mv linux linux-2.2.10

       chown -R root:root linux-2.2.10

       ln -s linux-2.2.10 linux

       cd linux

       make menuconfig

       make dep

       make bzImage

       make modules

       make modules_install

       cp /usr/src/linux/arch/i386/boot/bzImage
       /boot/vmlinuz-2.2.10

       rm /boot/System.*

      

Now we need to edit lilo.conf, rerun lilo, and reboot to make use of the new kernel. Like the IPSec documentation stresses, make sure your network works first before even attempting to install the software.

Lilo.conf should look like:

       map=/boot/map

       install=/boot/boot.b

       prompt

       timeout=100

       image=/boot/vmlinuz-2.2.10

       label=linux

       root=/dev/hda1

       read-only

       image=/boot/vmlinuz-2.2.5-12

       label=linuxold

       root=/dev/hda1

      

rerun lilo and you should see:

then reboot and you should be running kernel 2.2.10.

Now we need to edit the firewall rules, on both servers you should be masquerading the internal machines and using a default policy of denying forwarding for security with something like:

Server A:

       ipchains -A forward -p all -j MASQ -s 10.0.0.0/24 -d

Server B:

       ipchains -A forward -p all -j MASQ -s 192.168.0.0/24 -d

Remember to put these rules last in your firewalling script. You will also need to enable packet forwarding, edit the /etc/sysconfig/network and replace the line:

with the line:

You should now be able to ping Server B from Network A (ping 5.6.7.8), and you should also be able to ping Server A from Network B (ping 1.2.3.4).

Assuming all this works we can now attempt to install the IP Security software.

IPSec installation

Download the latest IPSec snapshot (version 1.0 will NOT work with 2.2.x kernels). Then go to /usr/local/src (or wherever), unpack the source and run the install program (make menugo typically for the ncurses based configuration). This will patch the kernel files, then run the kernel configuration, and then build the IPSec tools, and the kernel.

       tar -zvvxf /path/to/tarball/snapshot.tar.gz

       chown -R root:root freeswan-snap1999Jun14b

       cd freeswan-snap1999Jun14b

      

make sure you save the kernel configuration, even though the options are chosen they have not been saved. You will also have to rebuild the kernel as the "make menugo" command runs a "make zImage" which usually fails due to the large kernel sizes with 2.2.x. Once the compile is done it should have an error message or two, simply:

       make bzImage

       cp /usr/src/linux/arch/i386/boot/bzImage
      

Now we need to edit lilo.conf, rerun lilo, and reboot to make use of the new kernel.

Lilo.conf should look like:

       map=/boot/map

       install=/boot/boot.b

       prompt

       timeout=100

       image=/boot/vmlinuz-2.2.10-ipsec

       label=linux-ipsec

       root=/dev/hda1

       read-only

       image=/boot/vmlinuz-2.2.10

       label=linux

       root=/dev/hda1

      

rerun lilo and you should see:

then reboot and you should be running kernel 2.2.10 with IPSec support. As the machine reboots and starts the IPSec stuff you will see several errors, by default IPSec is set to use the eth999 interface, which of course does not exist. You should also add /usr/local/lib/ipsec to your path statement or else you will have to type the full path in a lot.

Configuring IPSec

We will initially use manual keying (i.e. for now we will ignore the pluto IKE daemon) as this makes life simpler. You will need to edit ipsec.conf and ipsec.conf. These two files will then need to be copied to the other server in a secure manner (ssh, floppy disk, etc.).

Here is a diagram of the network:

You will need to edit the ipsec.conf file, most of the defaults are fine but you will need to change the following:

       type=tunnel

       # left security gateway (public-network address)

       left=

       # next hop to reach right

       leftnexthop=

       # subnet behind left (omit if there is no subnet)

       leftsubnet=

       # right s.g., subnet behind it, and next hop to reach
       left

       right=

       rightnexthop=

       rightsubnet=

       #

       spibase=0x200

       # (manual) encryption/authentication algorithm and
       parameters to it

       esp=3des-md5-96

       espenckey=

      

replace the espenckey and espauthkey with new keys (using ranbits to generate a number, remmeber to leave the leading 0x that specifies it is a hex number) so that it looks like:

       type=tunnel

       # left security gateway (public-network address)

       left=1.2.3.4

       # next hop to reach right

       leftnexthop=1.2.3.1

       # subnet behind left (omit if there is no subnet)

       leftsubnet=10.0.0.0/24

       # right s.g., subnet behind it, and next hop to reach
       left

       right=5.6.7.8

       rightnexthop=5.6.7.1

       rightsubnet=192.168.0.0/24

       #

       spibase=0x200

       # (manual) encryption/authentication algorithm and
       parameters to it

       esp=3des-md5-96

       espenckey=some_auth_key_here (ranbits 192)

      

Once you have done this copy the files ipsec.conf and ipsec.secrets from the machine you edited them on to the other server in a secure manner. Now all that remains to be done is the addition of some firewall rules so that packets do not get masqueraded (instead we simply want them forwarded).

On Server A you should add the following rules:

       10.0.0.0/24 -d 192.168.0.0/24

       ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d
      

make sure these rules appear before the masquerading rule, it should look like this:

       # FORWARD RULES

       #

       ipchains -P forward DENY

       #

       ipchains -A forward -p all -j ACCEPT -s 10.0.0.0/24 -d
       192.168.0.0/24

       ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d
       10.0.0.0/24

       ipchains -A forward -p all -j MASQ -s 10.0.0.0/24 -d
      

And on server B you basically repeat the process:

       192.168.0.0/24 -d 10.0.0.0/24

       ipchains -A forward -p all -j ACCEPT -s 10.0.0.0/24 -d
      

make sure these rules appear before the masquerading rule, it should look like this:

       # FORWARD RULES

       #

       ipchains -P forward DENY

       #

       ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d
       10.0.0.0/24

       ipchains -A forward -p all -j ACCEPT -s 10.0.0.0/24 -d
       192.168.0.0/24

       ipchains -A forward -p all -j MASQ -s 192.168.0.0/24 -d
      

Starting up your connection

Now you should be able to bring up the ipsec tunnel on both machines manually and the machines on Network A should be able to talk to the machines on Network B with no problems.

and it should produce output similar to:

       is 36

       /usr/local/lib/ipsec/spi: message size is 132

      

To test it try pinging 192.168.0.2 from the 10.0.0.2 client (you cannot ping from 192.168.0.1 to 10.0.0.1 or the external gateway addresses since you have not configured tunnels to handle those packets). If this works then you have set it up correctly.