diff options
| author | Rene Mayrhofer <rene@mayrhofer.eu.org> | 2006-05-22 05:12:18 +0000 |
|---|---|---|
| committer | Rene Mayrhofer <rene@mayrhofer.eu.org> | 2006-05-22 05:12:18 +0000 |
| commit | aa0f5b38aec14428b4b80e06f90ff781f8bca5f1 (patch) | |
| tree | 95f3d0c8cb0d59d88900dbbd72110d7ab6e15b2a /doc/src/testing.html | |
| parent | 7c383bc22113b23718be89fe18eeb251942d7356 (diff) | |
| download | vyos-strongswan-aa0f5b38aec14428b4b80e06f90ff781f8bca5f1.tar.gz vyos-strongswan-aa0f5b38aec14428b4b80e06f90ff781f8bca5f1.zip | |
Import initial strongswan 2.7.0 version into SVN.
Diffstat (limited to 'doc/src/testing.html')
| -rw-r--r-- | doc/src/testing.html | 395 |
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/src/testing.html b/doc/src/testing.html new file mode 100644 index 000000000..8ffcca604 --- /dev/null +++ b/doc/src/testing.html @@ -0,0 +1,395 @@ +<html> +<head> +<title>Testing FreeS/WAN</title> + +<meta name="keywords" content="Linux, IPsec, VPN, security, FreeSWAN, testing"> + +<!-- + +Written by Sandy Harris for the Linux FreeS/WAN project +Freely distributable under the GNU General Public License + +More information at www.freeswan.org +Feedback to users@lists.freeswan.org + +CVS information: +RCS ID: $Id: testing.html,v 1.1 2004/03/15 20:35:24 as Exp $ +Last changed: $Date: 2004/03/15 20:35:24 $ +Revision number: $Revision: 1.1 $ + +CVS revision numbers do not correspond to FreeS/WAN release numbers. +--> +</head> + +<body> +<h1><a name="test.freeswan">Testing FreeS/WAN</a></h1> +This document discusses testing FreeS/WAN. + +<p>Not all types of testing are described here. Other parts of the +documentation describe some tests:</p> +<dl> + <dt><a href="install.html#testinstall">installation</a> document</dt> + <dd>testing for a successful install</dd> + <dt><a href="config.html#testsetup">configuration</a> document</dt> + <dd>basic tests for a working configuration</dd> + <dt><a href="web.html#interop.web">web links</a> document</dt> + <dd>General information on tests for interoperability between various + IPsec implementations. This includes links to several test sites.</dd> + <dt><a href="interop.html">interoperation</a> document.</dt> + <dd>More specific information on FreeS/WAN interoperation with other + implementations.</dd> + <dt><a href="performance.html">performance</a> document</dt> + <dd>performance measurements</dd> +</dl> + +<p>The test setups and procedures described here can also be used in other +testing, but this document focuses on testing the IPsec functionality of +FreeS/WAN.</p> + +<H2><A NAME="test.oe">Testing opportunistic connections</A></H2> + +<P>This section teaches you how to test your opportunistically encrypted (OE) +connections. To set up OE, please see the easy instructions in our +<A HREF="quickstart.html">quickstart guide</A>.</P> + +<H3>Basic OE Test</H3> + + +<P>This test is for basic OE functionality. +<!-- You may use it on an +<A HREF="quickstart.html#oppo.client">initiate-only OE</A> box or a +<A HREF="quickstart.html#opp.incoming">full OE</A> box. --> +For additional tests, keep reading.</P> + +<P>Be sure IPsec is running. You can see whether it is with:</P> +<PRE> ipsec setup status</PRE> +<P>If need be, you can restart it with:</P> +<PRE> service ipsec restart</PRE> + +<P>Load a FreeS/WAN test website from the host on which you're running +FreeS/WAN. Note: the feds may be watching these sites. Type one of:<P> +<PRE> links oetest.freeswan.org</PRE> +<PRE> links oetest.freeswan.nl</PRE> +<!--<PRE> links oetest.freeswan.ca</PRE>--> + +<P>A positive result looks like this:</P> + +<PRE> + You seem to be connecting from: 192.0.2.11 which DNS says is: + gateway.example.com + _________________________________________________________________ + + Status E-route + OE enabled 16 192.139.46.73/32 -> 192.0.2.11/32 => + tun0x2097@192.0.2.11 + OE enabled 176 192.139.46.77/32 -> 192.0.2.11/32 => + tun0x208a@192.0.2.11 +</PRE> + +<P>If you see this, congratulations! Your OE box will now encrypt +its own traffic whenever it can. If you have difficulty, +see our <A HREF="#oe.trouble">OE troubleshooting tips</A>. +</P> + +<H3>OE Gateway Test</H3> +<P>If you've set up FreeS/WAN to protect a subnet behind your gateway, +you'll need to run another simple test, which can be done from a machine +running any OS. That's right, your Windows box can be protected by +opportunistic encryption without any FreeS/WAN install or configuration +on that box. From <STRONG>each protected subnet node</STRONG>, +load the FreeS/WAN website with:</P> + +<PRE> links oetest.freeswan.org</PRE> +<PRE> links oetest.freeswan.nl</PRE> + +<P>A positive result looks like this:</P> +<PRE> + You seem to be connecting from: 192.0.2.98 which DNS says is: + box98.example.com + _________________________________________________________________ + + Status E-route + OE enabled 16 192.139.46.73/32 -> 192.0.2.98/32 => + tun0x134ed@192.0.2.11 + OE enabled 176 192.139.46.77/32 -> 192.0.2.11/32 => + tun0x134d2@192.0.2.11 +</PRE> + +<P>If you see this, congratulations! Your OE gateway will now encrypt +traffic for this subnet node whenever it can. If you have difficulty, see our +<A HREF="#oe.trouble">OE troubleshooting tips</A>. +</P> + + +<H3>Additional OE tests</H3> + +<P>When testing OE, you will often find it useful to execute this command +on the FreeS/WAN host:</P> +<PRE> ipsec eroute</PRE> + +<P>If you have established a connection (either for or for a subnet node) +you will see a result like:</P> + +<PRE> 192.0.2.11/32 -> 192.139.46.73/32 => tun0x149f@192.139.46.38 +</PRE> + +<P>Key:</P> +<TABLE> +<TR><TD>1.</TD> + <TD>192.0.2.11/32</TD> + <TD>Local start point of the protected traffic. + </TD></TR> +<TR><TD>2.</TD> + <TD>192.0.2.194/32</TD> + <TD>Remote end point of the protected traffic. + </TD></TR> +<TR><TD>3.</TD> + <TD>192.0.48.38</TD> + <TD>Remote FreeS/WAN node (gateway or host). + May be the same as (2). + </TD></TR> +<TR><TD>4.</TD> + <TD>[not shown]</TD> + <TD>Local FreeS/WAN node (gateway or host), where you've produced the output. + May be the same as (1). + </TD></TR> +</TABLE> + + +<P>For extra assurance, you may wish to use a packet sniffer such as +<A HREF="http://www.tcpdump.org">tcpdump</A> to verify that packets +are being encrypted. You should see output that indicates +<STRONG>ESP</STRONG> encrypted data, + for example:</P> + +<PRE> 02:17:47.353750 PPPoE [ses 0x1e12] IP 154: xy.example.com > oetest.freeswan.org: ESP(spi=0x87150d16,seq=0x55)</PRE> + + + +<h2><a name="test.uml">Testing with User Mode Linux</a></h2> + +<p><a href="http://user-mode-linux.sourceforge.net/">User Mode Linux</a> +allows you to run Linux as a user process on another Linux machine.</p> + +<p>As of 1.92, the distribution has a new directory named testing. It +contains a collection of test scripts and sample configurations. Using these, +you can bring up several copies of Linux in user mode and have them build +tunnels to each other. This lets you do some testing of a FreeS/WAN +configuration on a single machine.</p> + +<p>You need a moderately well-endowed machine for this to work well. Each UML +wants about 16 megs of memory by default, which is plenty for FreeS/WAN +usage. Typical regression testing only occasionally uses as many as 4 UMLs. +If one is doing nothing else with the machine (in particular, not running X +on it), then 128 megs and a 500MHz CPU are fine.</p> + +Documentation on these +scripts is <a href="umltesting.html">here</a>. There is also documentation +on automated testing <A href="makecheck.html">here</a>. + +<h2><a name="testnet">Configuration for a testbed network</a></h2> + +<p>A common test setup is to put a machine with dual Ethernet cards in +between two gateways under test. You need at least five machines; two +gateways, two clients and a testing machine in the middle.</p> + +<p>The central machine both routes packets and provides a place to run +diagnostic software for checking IPsec packets. See next section for +discussion of <a href="#tcpdump.faq">using tcpdump(8)</a> for this.</p> + +<p>This makes things more complicated than if you just connected the two +gateway machines directly to each other, but it also makes your test setup +much more like the environment you actually use IPsec in. Those environments +nearly always involve routing, and quite a few apparent IPsec failures turn +out to be problems with routing or with firewalls dropping packets. This +approach lets you deal with those problems on your test setup.</p> + +<p>What you end up with looks like:</p> + +<h3><a name="testbed">Testbed network</a></h3> +<pre> subnet a.b.c.0/24 + | + eth1 = a.b.c.1 + gate1 + eth0 = 192.168.p.1 + | + | + eth0 = 192.168.p.2 + route/monitor box + eth1 = 192.168.q.2 + | + | + eth0 = 192.168.q.1 + gate2 + eth1 = x.y.z.1 + | + subnet x.y.z.0/24</pre> +<pre>Where p and q are any convenient values that do not interfere with other +routes you may have. The ipsec.conf(5) file then has, among other things:</pre> +<pre>conn abc-xyz + left=192.168.p.1 + leftnexthop=192.168.p.2 + right=192.168.q.1 + rightnexthop=192.168.q.2</pre> + +<p>Once that works, you can remove the "route/monitor box", and connect the +two gateways to the Internet. The only parameters in ipsec.conf(5) that need +to change are the four shown above. You replace them with values appropriate +for your Internet connection, and change the eth0 IP addresses and the +default routes on both gateways.</p> + +<p>Note that nothing on either subnet needs to change. This lets you test +most of your IPsec setup before connecting to the insecure Internet.</p> + +<h3><a name="tcpdump.test">Using packet sniffers in testing</a></h3> + +<p>A number of tools are available for looking at packets. We will discuss +using <a href="http://www.tcpdump.org/">tcpdump(8)</a>, a common Linux tool +included in most distributions. Alternatives offerring more-or-less the same +functionality include:</p> +<dl> + <dt><a href="http://www.ethereal.com">Ethereal</a></dt> + <dd>Several people on our mailing list report a preference for this over + tcpdump.</dd> + <dt><a href="http://netgroup-serv.polito.it/windump/">windump</a></dt> + <dd>a Windows version of tcpdump(8), possibly handy if you have Windows + boxes in your network</dd> + <dt><a + href="http://reptile.rug.ac.be/~coder/sniffit/sniffit.html">Sniffit</a></dt> + <dd>A linux sniffer that we don't know much about. If you use it, please + comment on our mailing list.</dd> +</dl> + +<p>See also this <a +href="http://www.tlsecurity.net/unix/ids/sniffer/">index</a> of packet +sniffers.</p> + +<p>tcpdump(8) may misbehave if run on the gateways themselves. It is designed +to look into a normal IP stack and may become confused if you ask it to +display data from a stack which has IPsec in play.</p> + +<p>At one point, the problem was quite severe. Recent versions of tcpdump, +however, understand IPsec well enough to be usable on a gateway. You can get +the latest version from <a href="http://www.tcpdump.org/">tcpdump.org</a>.</p> + +<p>Even with a recent tcpdump, some care is required. Here is part of a post +from Henry on the topic:</p> +<pre>> a) data from sunset to sunrise or the other way is not being +> encrypted (I am using tcpdump (ver. 3.4) -x/ping -p to check +> packages) + +What *interface* is tcpdump being applied to? Use the -i option to +control this. It matters! If tcpdump is looking at the ipsecN +interfaces, e.g. ipsec0, then it is seeing the packets before they are +encrypted or after they are decrypted, so of course they don't look +encrypted. You want to have tcpdump looking at the actual hardware +interfaces, e.g. eth0. + +Actually, the only way to be *sure* what you are sending on the wire is to +have a separate machine eavesdropping on the traffic. Nothing you can do +on the machines actually running IPsec is 100% guaranteed reliable in this +area (although tcpdump is a lot better now than it used to be).</pre> + +<p>The most certain way to examine IPsec packets is to look at them on the +wire. For security, you need to be certain, so we recommend doing that. To do +so, you need a <strong>separate sniffer machine located between the two +gateways</strong>. This machine can be routing IPsec packets, but it must not +be an IPsec gateway. Network configuration for such testing is discussed <a +href="#testnet">above</a>.</p> + +<p>Here's another mailing list message with advice on using tcpdump(8):</p> +<pre>Subject: RE: [Users] Encrypted??? + Date: Thu, 29 Nov 2001 + From: "Joe Patterson" <jpatterson@asgardgroup.com> + +tcpdump -nl -i $EXT-IF proto 50 + +-nl tells it not to buffer output or resolve names (if you don't do that it +may confuse you by not outputing anything for a while), -i $EXT-IF (replace +with your external interface) tells it what interface to listen on, and +proto 50 is ESP. Use "proto 51" if for some odd reason you're using AH, and +"udp port 500" if you want to see the isakmp key exchange/tunnel setup +packets. + +You can also run `tcpdump -nl -i ipsec0` to see what traffic is on that +virtual interface. Anything you see there *should* be either encrypted or +dropped (unless you've turned on some strange options in your ipsec.conf +file) + +Another very handy thing is ethereal (http://www.ethereal.com/) which runs +on just about anything, has a nice gui interface (or a nice text-based +interface), and does a great job of protocol breakdown. For ESP and AH +it'll basically just tell you that there's a packet of that protocol, and +what the spi is, but for isakmp it'll actually show you a lot of the tunnel +setup information (until it gets to the point in the protocol where isakmp +is encrypted....)</pre> + +<h2><a name="verify.crypt">Verifying encryption</a></h2> + +<p>The question of how to verify that messages are actually encrypted has +been extensively discussed on the mailing list. See this <a +href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/07/msg00262.html">thread</a>.</p> + +<p>If you just want to verify that packets are encrypted, look at them with a +packet sniffer (see <a href="#tcpdump.test">previous section</a>) located +between the gateways. The packets should, except for some of the header +information, be utterly unintelligible. <strong>The output of good encryption +looks <em>exactly</em> like random noise</strong>. </p> + +<p>A packet sniffer can only tell you that the data you looked at was +encrypted. If you have stronger requirements -- for example if your security +policy requires verification that plaintext is not leaked during startup or +under various anomolous conditions -- then you will need to devise much more +thorough tests. If you do that, please post any results or methodological +details which your security policy allows you to make public.</p> + +<p>You can put recognizable data into ping packets with something like:</p> +<pre> ping -p feedfacedeadbeef 11.0.1.1</pre> + +<p>"feedfacedeadbeef" is a legal hexadecimal pattern that is easy to pick out +of hex dumps.</p> + +<p>For other protocols, you may need to check if you have encrypted data or +ASCII text. Encrypted data has approximately equal frequencies for all 256 +possible characters. ASCII text has most characters in the printable range +0x20-0x7f, a few control characters less than 0x20, and none at all in the +range 0x80-0xff. 0x20, space, is a good character to look for. In normal +English text space occurs about once in seven characters, versus about once +in 256 for random or encrypted data.</p> + +<p>One thing to watch for: the output of good compression, like that of good +encryption, looks just like random noise. You cannot tell just by looking at +a data stream whether it has been compressed, encrypted, or both. You need a +little care not to mistake compressed data for encrypted data in your +testing.</p> + +<p>Note also that weak encryption also produces random-looking output. You +cannot tell whether the encryption is strong by looking at the output. To be +sure of that, you would need to have both the algorithms and the +implementation examined by experts. </p> + +<p>For IPsec, you can get partial assurance from interoperability tests. See +our <a href="interop.html">interop</a> document. When twenty products all +claim to implement <a href="glossary.html#3DES">3DES</a>, and they all talk +to each other, you can be fairly sure they have it right. Of course, you +might wonder whether all the implementers are consipring to trick you or, +more plausibly, whether some implementations might have "back doors" so they +can get also it wrong when required.. If you're seriously worried about +things like that, you need to get the code you use audited (good luck if it +is not Open Source), or perhaps to talk to a psychiatrist about treatments +for paranoia. </p> + +<h2><a name="mail.test">Mailing list pointers</a></h2> + +<p>Additional information on testing can be found in these <a +href="mail.html">mailing list</a> messages:</p> +<ul> + <li>a user's detailed <a + href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00571.html">setup + diary</a> for his testbed network</li> + <li>a FreeS/WAN team member's <a + href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00425.html">notes</a> + from testing at an IPsec interop "bakeoff"</li> +</ul> +</body> +</html> |