It's time to have confidence in your firewall!
The VPN implementation used by Anaconda is an IPSec standard VPN. It is also a very simple manually keyed system. This works reasonably well in small scale installations but does require an amount of discipline to manually change keys on a regular basis.
As it is currently implemented, the Anaconda VPN environment is not suited for large-scale or road warrior use. It requires some changes in order to handle medium or large-scale VPN configurations as well as road warrior support.
However, these shortcomings do not stop the Anaconda environment from being useful for small-scale VPN deployments between regional offices over DSL or leased lines.
The concept of a VPN is very simple. It is a protected communication channel over an unprotected public thoroughfare. It is analogous to an armored vehicle travelling over public roads. At the top-level, a VPN consists of a small number of components, illustrated below:
In this diagram, there are two private intranets connected via the VPN. The VPN is created by the two VPN Gateways over the public Internet.
A VPN works by encapsulating data for one network inside of an ordinary IP packet and transporting that packet to another network. When the packet arrives at the destination network, it is unwrapped and delivered to the appropriate host on the destination network. By encapsulating the data using cryptographic techniques, the data is protected from tampering and snooping while it is transported over the public network.
Unfortunately, this same protection against tampering makes it difficult to set up a VPN when the security perimeter is protected by an address translation firewall such as Anaconda. The solution is to implement the VPN on the firewall and allow it to straddle both sides so that it can capture packets from the green network and pass them, encapsulated, over the Internet without being tampered with by the address translation part of the firewall.
When setting up the VPN, there are a few things that must be in place before the VPN can operate correctly. Those things are:
Good connectivity is extremely important because if there is high packet loss or latency, it will be reflected in the VPN's performance. The VPN is extremely persistent in trying to maintain a connection and re-establish any connections that may get broken but it can't work miracles when the network over which it travels is broken. One can test the connectivity by a combination of ping and traceroute. Ping should show low packet loss and traceroute should show reliable routing.
It's essential that every network joined by the VPN has independent, non-overlapping IP address spaces. For example, if one network is 192.168.0.0/24 and the other network is 192.168.0.128/25, the VPN connection will not work. However, if the other network was 192.168.1.0/25, the VPN would work because the address ranges do not overlap.
Routing is another source of errors when setting up a VPN. It's important for all hosts that must communicate across the VPN to be configured so that the VPN specific routes are known and handled properly. A common way to deal with this is to use a router as the default gateway and reroute traffic as appropriate from that router. The primary advantage of this technique is that routes are controlled in one place. The disadvantage is that in a non switched network, there can be some additional network congestion and that the router is a single point of failure. If there is no internal router pre-existing, the Anaconda machine will usually be the network's default route and can be used as a general router.
In order to turn on the VPN on a Anaconda firewall, there are three essential bits of information that must be collected from each side of the VPN (shown below).
The three bits of information are the: firewall's red interface IP address, the default route for the firewall, and the network and net mask of the VPN connected network (usually green network). This information can be extracted from a running firewalls using two command. One can extract the network and net mask information using the command "ifconfig
The gray box contains the IP address of the red interface. To get the rest of the information, we use the netstat command as shown in the box below.
The leftmost box contains the network for the green interface (see Iface column on far right). The middle a box contains the default gateway for the firewall. The rightmost box contains the net mask for the green network (on same line as green interface). Unfortunately, the net mask is in the wrong form. Instead of dotted notation, the netmask must be in "slash notation". In this case, slash notation would be "/24". The table below provides a conversion between slash notation and dotted notation netmask.
Once this information has been gathered for both sides of the VPN, then one can configure the firewall and activate the VPN. A VPN data worksheet is provided as part of this document to help organize the information collection process.
The Anaconda VPN is a manually keyed system. This means that you must use a single shared secret for all VPN nodes which becomes the key for encrypting all traffic. Keys must be changed regularly and hidden from view so that it would be difficult if not impossible for someone to tap the VPN. Future versions will replace manual keying with automatic keying and RSA based authentication.
Manually keyed systems should use relatively long random bit strings. A simple technique for generating keys would be to take the output of "ps -aux" passed through md5sum. This is still a very weak method of generating a manual key but it's far stronger than usual human generated passwords. Generate the key, record it somewhere safe and don't lose it until you've replaced it.
Anaconda VPN details
Before activating the VPN:
* Verify you can ping and traceroute from the green network host to the remote firewall. Do not proceed any further if you cannot reach the other the firewall by ping and traceroute.
Setting up the VPN:
At this point, all the data you entered should be visible in the current connections section of the page. Verify that you entered all data correctly and then repeat the above steps on the other end of the VPN. Once both ends of the VPN have been filled with identical data, activate the connections:
Verifying that the VPN is up is fairly easy. The first test is to try and ping a system on the remote end using its real IP address. If that doesn't work, you'll need to run the netstat command and verify that the VPN has been activated and entered routes to the other end of the VPN. You should see something like the following:
Notice the two routes on interface ipsec0. Both of them will be there if the VPN is up and running. If they are not there, then something is wrong with the parameters entered into the VPN configuration or the network between the two firewalls.
Note: it does not matter which system is considered left or right. Pick a convention for which system is left and which system is right and stick to that convention. You pick to be the left or right side system must be that system on both ends of the VPN.
However, there was a report on the mailing list that this is wrong, or at least open to interpretation...
Like many, I read the HOW-TO, and it said to fill in the left and right information,passphrase, et al on both Anaconda VPN partners, and they would figure out who is leftand who is right. Nope. If you regard Left as Local, and Right as Remote, it works. For two Anaconda boxes A and Z: The Left information of Box A is the Right information for Box Z. Conversely, the Right information of Box A is the Left information for Box Z. The pass phrases are the same. So simple, yet hair-tearing.Kurt Freiberger
-- EricOberlander - 09 Feb 2003
Note: don't guess! Verify parameters on each firewall using the techniques described earlier. Incorrect values can cause hours of debugging fun.
Connection name _______________________________________
Left-hand VPN parameters:
Red Network IP address: _______________________________
Firewall Gateway Address: _____________________________
VPN connected network/netmask: ________________________
Right-hand VPN parameters:
Red Network IP address: ________________________________
Firewall Gateway Address: _____________________________
VPN connected network/netmask: __________________________
-- EricSJohansson - 04 Jan 2002
-- OpenSSH for Windowshttp://www.networksimplicity.com/openssh/
How to connect a Win2k or XP box to an Anaconda using the built in ipsec of Win2k or XP
NOTE: if your red ip address changes like the weather, you will have to register your Anaconda with one of the dynamic dns services such as dyndns.org. Also note that this cannot be done through the Anaconda Web interface, it must be done from a command line, and if you use the connections page of the web interface, it will wipe out all your settings.
Connecting a Win2k/XP box to an Anaconda using the built in ipsec of Win2k Pro/XP is accomplished in about ten minutes. The same should work for a windows XP box. Note that you will have to edit the
Before you start, if you have never set up a vpn on Anaconda before, please go to the vpn connections page in the web interface, and create a dummy one. If you have created vpn's in the past or already have vpns, you can skip this paragraph. By a dummy one I mean place any valid values in the left/right fields (any valid ip address), and give it a name, a preshared key and save it. If it saves successfully, then delete it. What this does is initialize the
Next, make sure that VPN's are enabled in your web interface. That is the check box on the VPN page that enables or disables vpns. Just check the box and hit save. Nothing else needs to be done, don't worry about hitting restart at this point.
In my situation, I have a win2k box behind an Assante Cable/DSL router connected to a cable modem. The Anaconda box protects a private network with a subnet of 192.168.1.x and I am running a subnet of 192.168.10.x at my end. You need different subnets at each end otherwise the routing will not behave properly. By this I mean that you could not setup the network behind the Anaconda to be 192.168.1.x and then have your road warrior be 192.168.1.x, it would have to be 192.168.2.x or some other private ip address. In the logging examples, you will see 255.255.255.255 as an ip address, this is a fictional address for this example. My particular machine is 192.168.10.159 and you will see that entered in the conf files, etc. And the Anaconda box is 192.168.1.254, again you will see this in the logs, etc. Note that my win2k machine is a different subnet to the Anaconda machine.
Now on to the good stuff! First, make sure your Win2k box is ready to do the job, Service Pack 3 must be installed or at least the high encryption pack, it installs 3DES which is needed by Anaconda. This is not necessary for XP as it contains 3DES already. Note Microsoft has made some updates to Ipsec in service pack 3.
For Windows 2000 get the ipsec policy editor from here :http://www.microsoft.com/windows2000/techinfo/reskit/tools/default.asp
For Windows XP you will need the Ipseccmd program : You have to install the Win XP Support tools. They reside on your Win XP CD in the directory \SUPPORT\TOOLS. Just start setup.exe in this directory. You have to select a Complete installation to get ipseccmd.
Next download this utility:http://vpn.ebootis.de/package.zip and extract the contents to the same place that the
Also to make sure you know what is going on with the Anaconda box, download and install
Make sure you turn on SSH on your Anaconda box so that Putty or another Secure Shell can access the command line. To do this, in the web interface, go to system, and then click on remote access. Click the checkbox and hit save.
Now, you need to setup the
conn roadwarrior compress=no left=(red address or dynamic dns name) leftsubnet=192.168.1.0/24 <-- subnet behind Anaconda leftnexthop=%defaultroute type=tunnel authby=secret pfs=yes right=%any rightsubnet=192.168.10.159/32 <--if you are behind a firewall
or other router put private address here otherwise leave blank rightnexthop=%defaultroute auto=add
In the ipsec.secrets on the Anaconda file make sure you have
Now for the Win2k setup:
conn HEADOFFICE left=(red address of Anaconda or dynamic dns name of Anaconda) leftsubnet=192.168.1.0/24 <-- Subnet behind Anaconda right=%any presharedkey=PreShared secret here network=auto auto=start pfs=yes
Error 0xcbbb0005 occured:Source and Dest address are not separated by a designated character
Now, on the windows machine from a DOS box, change directories to where the
C:\Program Files\Resource Kit>ipsec.exeIPSec Version 2.1.4 (c) 2001,2002 Marcus MuellerGetting running Config ...Microsoft's Windows 2000 identifiedHost name is: roadwarriorNo RAS connections found.LAN IP address: 192.168.10.159Setting up IPSec ... Deactivating old policy... Removing old policy...Connection HEADOFFICE: MyTunnel : 192.168.10.159 MyNet : 192.168.10.159/255.255.255.255 PartnerTunnel: (Red Anaconda address or Dyn DNS Name) PartnerNet : 192.168.1.0/255.255.255.0 CA (ID) : Preshared Key ****************** PFS : y Auto : start Auth.Mode : MD5 Rekeying : 3600S/50000K Activating policy...C:\Program Files\Resource Kit>
Next from the win2k box ping the Green IP Address of the Anaconda box, after a couple of pings, it should get a reply. (Takes two tries with my setup, I have heard of it taking four or five) To ping type the following:
ping (green address of Anaconda)
That should give you something like this:
C:\>ping 192.168.1.254Pinging 192.168.1.254 with 32 bytes of data:Reply from 192.168.1.254: bytes=32 time=51ms TTL=255Reply from 192.168.1.254: bytes=32 time=60ms TTL=255Reply from 192.168.1.254: bytes=32 time=50ms TTL=255Reply from 192.168.1.254: bytes=32 time=50ms TTL=255Ping statistics for 192.168.1.254: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)Approximate round trip times in milli-seconds: Minimum = 50ms, Maximum = 60ms, Average = 52ms
Ideally to make sure things are going as planned, have a putty (SSH - Secure Shell) session running to your Anaconda box so you can examine /var/log/secure. For more information on SSH and how to set it up, look in the AnacondaFAQ for How do I turn on SSH.
As for the Anaconda log it should show something like the following:
cat /var/log/secureDec 31 17:30:42 Anaconda0002 pluto: "roadwarrior" 255.255.255.255 #5:
responding to Main Mode from unknown peer 255.255.255.255Dec 31 17:30:43 Anaconda0002 pluto: "roadwarrior" 255.255.255.255 #3:
Peer ID is ID_IPV4_ADDR: '192.168.10.159'Dec 31 17:30:43 Anaconda0002 pluto: "roadwarrior" 255.255.255.255 #3:
sent MR3, ISAKMP SA establishedDec 31 17:30:43 Anaconda0002 pluto: "roadwarrior" 255.255.255.255 #6:
responding to Quick ModeDec 31 17:30:43 Anaconda0002 pluto: "roadwarrior" 255.255.255.255 #6:
IPsec SA established
The above log can also show you what went wrong, or at least the vital information to post to the list to show us what went wrong so we can help you correct it.
If you fail to connect on the first attempt or try to reconnect after the connection goes idle, I have found that I have to restart the vpn on both ends, on the win2k box type
Then on the Anaconda, use the web interface to restart the vpn. Now start the win2k ipsec again.
Now you know how to connect a win2k box to an Anaconda using the built in ipsec of Win2k, thanks to Darren Critchley.
We will continue to develop this site to bring you further info and resources. Please contact us for further info and a free firewall consultation - firstname.lastname@example.org
Images and content are copyright to Cipher-IT Ltd
Site designed by Cipher-IT Ltd