[thirdparty/strongswan.git] / doc / src / testing.html

<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>&gt; a) data from sunset to sunrise or the other way is not being
&gt; encrypted (I am using tcpdump (ver. 3.4) -x/ping -p to check
&gt; 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" &lt;jpatterson@asgardgroup.com&gt;

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>
Commit	Line	Data
997358a6 MW	1	<html>
	2	<head>
	3	<title>Testing FreeS/WAN</title>
	4
	5	<meta name="keywords" content="Linux, IPsec, VPN, security, FreeSWAN, testing">
	6
	7	<!--
	8
	9	Written by Sandy Harris for the Linux FreeS/WAN project
	10	Freely distributable under the GNU General Public License
	11
	12	More information at www.freeswan.org
	13	Feedback to users@lists.freeswan.org
	14
	15	CVS information:
	16	RCS ID: $Id: testing.html,v 1.1 2004/03/15 20:35:24 as Exp $
	17	Last changed: $Date: 2004/03/15 20:35:24 $
	18	Revision number: $Revision: 1.1 $
	19
	20	CVS revision numbers do not correspond to FreeS/WAN release numbers.
	21	-->
	22	</head>
	23
	24	<body>
	25	<h1><a name="test.freeswan">Testing FreeS/WAN</a></h1>
	26	This document discusses testing FreeS/WAN.
	27
	28	<p>Not all types of testing are described here. Other parts of the
	29	documentation describe some tests:</p>
	30	<dl>
	31	<dt><a href="install.html#testinstall">installation</a> document</dt>
	32	<dd>testing for a successful install</dd>
	33	<dt><a href="config.html#testsetup">configuration</a> document</dt>
	34	<dd>basic tests for a working configuration</dd>
	35	<dt><a href="web.html#interop.web">web links</a> document</dt>
	36	<dd>General information on tests for interoperability between various
	37	IPsec implementations. This includes links to several test sites.</dd>
	38	<dt><a href="interop.html">interoperation</a> document.</dt>
	39	<dd>More specific information on FreeS/WAN interoperation with other
	40	implementations.</dd>
	41	<dt><a href="performance.html">performance</a> document</dt>
	42	<dd>performance measurements</dd>
	43	</dl>
	44
	45	<p>The test setups and procedures described here can also be used in other
	46	testing, but this document focuses on testing the IPsec functionality of
	47	FreeS/WAN.</p>
	48
	49	<H2><A NAME="test.oe">Testing opportunistic connections</A></H2>
	50
	51	<P>This section teaches you how to test your opportunistically encrypted (OE)
	52	connections. To set up OE, please see the easy instructions in our
	53	<A HREF="quickstart.html">quickstart guide</A>.</P>
	54
	55	<H3>Basic OE Test</H3>
	56
	57
	58	<P>This test is for basic OE functionality.
	59	<!-- You may use it on an
	60	<A HREF="quickstart.html#oppo.client">initiate-only OE</A> box or a
	61	<A HREF="quickstart.html#opp.incoming">full OE</A> box. -->
	62	For additional tests, keep reading.</P>
	63
	64	<P>Be sure IPsec is running. You can see whether it is with:</P>
65	<PRE> ipsec setup status</PRE>
66	<P>If need be, you can restart it with:</P>
67	<PRE> service ipsec restart</PRE>
68
69	<P>Load a FreeS/WAN test website from the host on which you're running
70	FreeS/WAN. Note: the feds may be watching these sites. Type one of:<P>
71	<PRE> links oetest.freeswan.org</PRE>
72	<PRE> links oetest.freeswan.nl</PRE>
73	<!--<PRE> links oetest.freeswan.ca</PRE>-->
74
75	<P>A positive result looks like this:</P>
76
77	<PRE>
78	You seem to be connecting from: 192.0.2.11 which DNS says is:
79	gateway.example.com
80	_________________________________________________________________
81
82	Status E-route
83	OE enabled 16 192.139.46.73/32 -> 192.0.2.11/32 =>
84	tun0x2097@192.0.2.11
85	OE enabled 176 192.139.46.77/32 -> 192.0.2.11/32 =>
86	tun0x208a@192.0.2.11
87	</PRE>
88
89	<P>If you see this, congratulations! Your OE box will now encrypt
90	its own traffic whenever it can. If you have difficulty,
91	see our <A HREF="#oe.trouble">OE troubleshooting tips</A>.
92	</P>
93
94	<H3>OE Gateway Test</H3>
95	<P>If you've set up FreeS/WAN to protect a subnet behind your gateway,
96	you'll need to run another simple test, which can be done from a machine
97	running any OS. That's right, your Windows box can be protected by
98	opportunistic encryption without any FreeS/WAN install or configuration
99	on that box. From <STRONG>each protected subnet node</STRONG>,
100	load the FreeS/WAN website with:</P>
101
102	<PRE> links oetest.freeswan.org</PRE>
103	<PRE> links oetest.freeswan.nl</PRE>
104
105	<P>A positive result looks like this:</P>
106	<PRE>
107	You seem to be connecting from: 192.0.2.98 which DNS says is:
108	box98.example.com
109	_________________________________________________________________
110
111	Status E-route
112	OE enabled 16 192.139.46.73/32 -> 192.0.2.98/32 =>
113	tun0x134ed@192.0.2.11
114	OE enabled 176 192.139.46.77/32 -> 192.0.2.11/32 =>
115	tun0x134d2@192.0.2.11
116	</PRE>
117
118	<P>If you see this, congratulations! Your OE gateway will now encrypt
119	traffic for this subnet node whenever it can. If you have difficulty, see our
120	<A HREF="#oe.trouble">OE troubleshooting tips</A>.
121	</P>
122
123
124	<H3>Additional OE tests</H3>
125
126	<P>When testing OE, you will often find it useful to execute this command
127	on the FreeS/WAN host:</P>
128	<PRE> ipsec eroute</PRE>
129
130	<P>If you have established a connection (either for or for a subnet node)
131	you will see a result like:</P>
132
133	<PRE> 192.0.2.11/32 -> 192.139.46.73/32 => tun0x149f@192.139.46.38
134	</PRE>
135
136	<P>Key:</P>
137	<TABLE>
138	<TR><TD>1.</TD>
139	<TD>192.0.2.11/32</TD>
140	<TD>Local start point of the protected traffic.
141	</TD></TR>
142	<TR><TD>2.</TD>
143	<TD>192.0.2.194/32</TD>
144	<TD>Remote end point of the protected traffic.
145	</TD></TR>
146	<TR><TD>3.</TD>
147	<TD>192.0.48.38</TD>
148	<TD>Remote FreeS/WAN node (gateway or host).
149	May be the same as (2).
150	</TD></TR>
151	<TR><TD>4.</TD>
152	<TD>[not shown]</TD>
153	<TD>Local FreeS/WAN node (gateway or host), where you've produced the output.
154	May be the same as (1).
155	</TD></TR>
156	</TABLE>
157
158
159	<P>For extra assurance, you may wish to use a packet sniffer such as
160	<A HREF="http://www.tcpdump.org">tcpdump</A> to verify that packets
161	are being encrypted. You should see output that indicates
162	<STRONG>ESP</STRONG> encrypted data,
163	for example:</P>
164
165	<PRE> 02:17:47.353750 PPPoE [ses 0x1e12] IP 154: xy.example.com > oetest.freeswan.org: ESP(spi=0x87150d16,seq=0x55)</PRE>
166
167
168
169	<h2><a name="test.uml">Testing with User Mode Linux</a></h2>
170
171	<p><a href="http://user-mode-linux.sourceforge.net/">User Mode Linux</a>
172	allows you to run Linux as a user process on another Linux machine.</p>
173
174	<p>As of 1.92, the distribution has a new directory named testing. It
175	contains a collection of test scripts and sample configurations. Using these,
176	you can bring up several copies of Linux in user mode and have them build
177	tunnels to each other. This lets you do some testing of a FreeS/WAN
178	configuration on a single machine.</p>
179
180	<p>You need a moderately well-endowed machine for this to work well. Each UML
181	wants about 16 megs of memory by default, which is plenty for FreeS/WAN
182	usage. Typical regression testing only occasionally uses as many as 4 UMLs.
183	If one is doing nothing else with the machine (in particular, not running X
184	on it), then 128 megs and a 500MHz CPU are fine.</p>
185
186	Documentation on these
187	scripts is <a href="umltesting.html">here</a>. There is also documentation
188	on automated testing <A href="makecheck.html">here</a>.
189
190	<h2><a name="testnet">Configuration for a testbed network</a></h2>
191
192	<p>A common test setup is to put a machine with dual Ethernet cards in
193	between two gateways under test. You need at least five machines; two
194	gateways, two clients and a testing machine in the middle.</p>
195
196	<p>The central machine both routes packets and provides a place to run
197	diagnostic software for checking IPsec packets. See next section for
198	discussion of <a href="#tcpdump.faq">using tcpdump(8)</a> for this.</p>
199
200	<p>This makes things more complicated than if you just connected the two
201	gateway machines directly to each other, but it also makes your test setup
202	much more like the environment you actually use IPsec in. Those environments
203	nearly always involve routing, and quite a few apparent IPsec failures turn
204	out to be problems with routing or with firewalls dropping packets. This
205	approach lets you deal with those problems on your test setup.</p>
206
207	<p>What you end up with looks like:</p>
208
209	<h3><a name="testbed">Testbed network</a></h3>
210	<pre> subnet a.b.c.0/24
211	\|
212	eth1 = a.b.c.1
213	gate1
214	eth0 = 192.168.p.1
215	\|
216	\|
217	eth0 = 192.168.p.2
218	route/monitor box
219	eth1 = 192.168.q.2
220	\|
221	\|
222	eth0 = 192.168.q.1
223	gate2
224	eth1 = x.y.z.1
225	\|
226	subnet x.y.z.0/24</pre>
227	<pre>Where p and q are any convenient values that do not interfere with other
228	routes you may have. The ipsec.conf(5) file then has, among other things:</pre>
229	<pre>conn abc-xyz
230	left=192.168.p.1
231	leftnexthop=192.168.p.2
232	right=192.168.q.1
233	rightnexthop=192.168.q.2</pre>
234
235	<p>Once that works, you can remove the "route/monitor box", and connect the
236	two gateways to the Internet. The only parameters in ipsec.conf(5) that need
237	to change are the four shown above. You replace them with values appropriate
238	for your Internet connection, and change the eth0 IP addresses and the
239	default routes on both gateways.</p>
240
241	<p>Note that nothing on either subnet needs to change. This lets you test
242	most of your IPsec setup before connecting to the insecure Internet.</p>
243
244	<h3><a name="tcpdump.test">Using packet sniffers in testing</a></h3>
245
246	<p>A number of tools are available for looking at packets. We will discuss
247	using <a href="http://www.tcpdump.org/">tcpdump(8)</a>, a common Linux tool
248	included in most distributions. Alternatives offerring more-or-less the same
249	functionality include:</p>
250	<dl>
251	<dt><a href="http://www.ethereal.com">Ethereal</a></dt>
252	<dd>Several people on our mailing list report a preference for this over
253	tcpdump.</dd>
254	<dt><a href="http://netgroup-serv.polito.it/windump/">windump</a></dt>
255	<dd>a Windows version of tcpdump(8), possibly handy if you have Windows
256	boxes in your network</dd>
257	<dt><a
258	href="http://reptile.rug.ac.be/~coder/sniffit/sniffit.html">Sniffit</a></dt>
259	<dd>A linux sniffer that we don't know much about. If you use it, please
260	comment on our mailing list.</dd>
261	</dl>
262
263	<p>See also this <a
264	href="http://www.tlsecurity.net/unix/ids/sniffer/">index</a> of packet
265	sniffers.</p>
266
267	<p>tcpdump(8) may misbehave if run on the gateways themselves. It is designed
268	to look into a normal IP stack and may become confused if you ask it to
269	display data from a stack which has IPsec in play.</p>
270
271	<p>At one point, the problem was quite severe. Recent versions of tcpdump,
272	however, understand IPsec well enough to be usable on a gateway. You can get
273	the latest version from <a href="http://www.tcpdump.org/">tcpdump.org</a>.</p>
274
275	<p>Even with a recent tcpdump, some care is required. Here is part of a post
276	from Henry on the topic:</p>
277	<pre>> a) data from sunset to sunrise or the other way is not being
278	> encrypted (I am using tcpdump (ver. 3.4) -x/ping -p to check
279	> packages)
280
281	What interface is tcpdump being applied to? Use the -i option to
282	control this. It matters! If tcpdump is looking at the ipsecN
283	interfaces, e.g. ipsec0, then it is seeing the packets before they are
284	encrypted or after they are decrypted, so of course they don't look
285	encrypted. You want to have tcpdump looking at the actual hardware
286	interfaces, e.g. eth0.
287
288	Actually, the only way to be sure what you are sending on the wire is to
289	have a separate machine eavesdropping on the traffic. Nothing you can do
290	on the machines actually running IPsec is 100% guaranteed reliable in this
291	area (although tcpdump is a lot better now than it used to be).</pre>
292
293	<p>The most certain way to examine IPsec packets is to look at them on the
294	wire. For security, you need to be certain, so we recommend doing that. To do
295	so, you need a <strong>separate sniffer machine located between the two
296	gateways</strong>. This machine can be routing IPsec packets, but it must not
297	be an IPsec gateway. Network configuration for such testing is discussed <a
298	href="#testnet">above</a>.</p>
299
300	<p>Here's another mailing list message with advice on using tcpdump(8):</p>
301	<pre>Subject: RE: [Users] Encrypted???
302	Date: Thu, 29 Nov 2001
303	From: "Joe Patterson" <jpatterson@asgardgroup.com>
304
305	tcpdump -nl -i $EXT-IF proto 50
306
307	-nl tells it not to buffer output or resolve names (if you don't do that it
308	may confuse you by not outputing anything for a while), -i $EXT-IF (replace
309	with your external interface) tells it what interface to listen on, and
310	proto 50 is ESP. Use "proto 51" if for some odd reason you're using AH, and
311	"udp port 500" if you want to see the isakmp key exchange/tunnel setup
312	packets.
313
314	You can also run `tcpdump -nl -i ipsec0` to see what traffic is on that
315	virtual interface. Anything you see there should be either encrypted or
316	dropped (unless you've turned on some strange options in your ipsec.conf
317	file)
318
319	Another very handy thing is ethereal (http://www.ethereal.com/) which runs
320	on just about anything, has a nice gui interface (or a nice text-based
321	interface), and does a great job of protocol breakdown. For ESP and AH
322	it'll basically just tell you that there's a packet of that protocol, and
323	what the spi is, but for isakmp it'll actually show you a lot of the tunnel
324	setup information (until it gets to the point in the protocol where isakmp
325	is encrypted....)</pre>
326
327	<h2><a name="verify.crypt">Verifying encryption</a></h2>
328
329	<p>The question of how to verify that messages are actually encrypted has
330	been extensively discussed on the mailing list. See this <a
331	href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/07/msg00262.html">thread</a>.</p>
332
333	<p>If you just want to verify that packets are encrypted, look at them with a
334	packet sniffer (see <a href="#tcpdump.test">previous section</a>) located
335	between the gateways. The packets should, except for some of the header
336	information, be utterly unintelligible. <strong>The output of good encryption
337	looks <em>exactly</em> like random noise</strong>. </p>
338
339	<p>A packet sniffer can only tell you that the data you looked at was
340	encrypted. If you have stronger requirements -- for example if your security
341	policy requires verification that plaintext is not leaked during startup or
342	under various anomolous conditions -- then you will need to devise much more
343	thorough tests. If you do that, please post any results or methodological
344	details which your security policy allows you to make public.</p>
345
346	<p>You can put recognizable data into ping packets with something like:</p>
347	<pre> ping -p feedfacedeadbeef 11.0.1.1</pre>
348
349	<p>"feedfacedeadbeef" is a legal hexadecimal pattern that is easy to pick out
350	of hex dumps.</p>
351
352	<p>For other protocols, you may need to check if you have encrypted data or
353	ASCII text. Encrypted data has approximately equal frequencies for all 256
354	possible characters. ASCII text has most characters in the printable range
355	0x20-0x7f, a few control characters less than 0x20, and none at all in the
356	range 0x80-0xff. 0x20, space, is a good character to look for. In normal
357	English text space occurs about once in seven characters, versus about once
358	in 256 for random or encrypted data.</p>
359
360	<p>One thing to watch for: the output of good compression, like that of good
361	encryption, looks just like random noise. You cannot tell just by looking at
362	a data stream whether it has been compressed, encrypted, or both. You need a
363	little care not to mistake compressed data for encrypted data in your
364	testing.</p>
365
366	<p>Note also that weak encryption also produces random-looking output. You
367	cannot tell whether the encryption is strong by looking at the output. To be
368	sure of that, you would need to have both the algorithms and the
369	implementation examined by experts. </p>
370
371	<p>For IPsec, you can get partial assurance from interoperability tests. See
372	our <a href="interop.html">interop</a> document. When twenty products all
373	claim to implement <a href="glossary.html#3DES">3DES</a>, and they all talk
374	to each other, you can be fairly sure they have it right. Of course, you
375	might wonder whether all the implementers are consipring to trick you or,
376	more plausibly, whether some implementations might have "back doors" so they
377	can get also it wrong when required.. If you're seriously worried about
378	things like that, you need to get the code you use audited (good luck if it
379	is not Open Source), or perhaps to talk to a psychiatrist about treatments
380	for paranoia. </p>
381
382	<h2><a name="mail.test">Mailing list pointers</a></h2>
383
384	<p>Additional information on testing can be found in these <a
385	href="mail.html">mailing list</a> messages:</p>
386	<ul>
387	<li>a user's detailed <a
388	href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00571.html">setup
389	diary</a> for his testbed network</li>
390	<li>a FreeS/WAN team member's <a
391	href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00425.html">notes</a>
392	from testing at an IPsec interop "bakeoff"</li>
393	</ul>
394	</body>
395	</html>