Introduction to FreeS/WAN

named · things you + should know before trying to use FreeS/WAN.

   echo 1 > /proc/sys/net/ipv4/conf/eth0/rp_filter
    version 2
    dump
+    plutobackgroundload
+    no_eroute_pass
+    lifetime
+    rekeystart
+    rekeytries
    interfaces=%defaultroute
+    plutoload=%search
+    plutostart=%search
+    uniqueids=yes
    authby=rsasig   ## not secret!!!
+    leftrsasigkey=%dnsondemand ## looks up missing keys in DNS when needed.
+    rightrsasigkey=%dnsondemand
    rpm -e freeswan
    rpm -e freeswan-module
    rpm -ivh freeswan-module-2.04_2.4.20_20.9-0.i386.rpm
    rpm -ivh freeswan-userland-2.04_2.4.20_20.9-0.i386.rpm
    cat /etc/ipsec.conf /etc/ipsec.conf.rpmsave > /etc/ipsec.conf.tmp
+    mv /etc/ipsec.conf.tmp /etc/ipsec.conf
    ncftpget ftp://ftp.xs4all.nl/pub/crypto/freeswan/binaries/RedHat-RPMs/`uname -r | tr -d 'a-wy-z'`/\*
    freeswan-module-2.04_2.4.20_20.9-0.i386.rpm
+    freeswan-userland-2.04_2.4.20_20.9-0.i386.rpm
+    freeswan-rpmsign.asc
    rpm --import freeswan-rpmsign.asc
    pgp -ka freeswan-rpmsign.asc
    rpm --checksig freeswan*.rpm 
    freeswan-module-2.04_2.4.20_20.9-0.i386.rpm: pgp md5 OK
+    freeswan-userland-2.04_2.4.20_20.9-0.i386.rpm: pgp md5 OK
    su
    rpm -ivh freeswan*.rpm
    service ipsec start
    ipsec verify
+    Checking your system to see if IPsec got installed and started correctly
+    Version check and ipsec on-path                             [OK]
+    Checking for KLIPS support in kernel                        [OK]
+    Checking for RSA private key (/etc/ipsec.secrets)           [OK]
+    Checking that pluto is running                              [OK]
+    ...
    [root@xy root]# hostname --fqdn
+    xy.example.com
    ipsec showhostkey --txt @xy.example.com
+    ; RSA 2192 bits   xy.example.com   Thu Jan  2 12:41:44 2003
+        IN      TXT     "X-IPsec-Server(10)=@xy.example.com" 
+    "AQOF8tZ2... ...+buFuFn/"
+
    ipsec verify --host xy.example.com
    ...
+    Looking for TXT in forward map: xy.example.com          [OK]
+    ...
    config setup
+        myid=@myname.freedns.example.com
    service ipsec restart
    ipsec showhostkey --txt 192.0.2.11
    ; RSA 2048 bits  xy.example.com   Sat Apr 15 13:53:22 2000
+    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
    ipsec verify --host xy.example.com
    ...
+    Looking for TXT in reverse map: 11.2.0.192.in-addr.arpa [OK]
+    ...
    service ipsec restart
    ipsec setup status
    service ipsec restart
   links oetest.freeswan.org
   links oetest.freeswan.nl
+   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
+
    [root@xy root]# cat /etc/ipsec.d/policies/private-or-clear
+    # This file defines the set of CIDRs (network/mask-length) to which
+    # communication should be private, if possible, but in the clear otherwise.
+    ....
+    0.0.0.0/0
    ipsec auto --rereadgroups
    [root@xy root]# cd /etc/ipsec.d/policies
+    [root@xy policies]# cat private
+        192.0.2.96/27              # The finance department
+        192.0.2.192/29             # HR
+	192.0.2.12                 # HR gateway
+        irc.private.example.com    # Private IRC server
+  
+    [root@xy policies]# cat private-or-clear
+        0.0.0.0/0                  # My default policy: try to encrypt.
+
+    [root@xy policies]# cat clear
+        192.0.2.18/32              # My POP3 server
+        192.0.2.19/32              # My Web proxy
+
+    [root@xy policies]# cat block
+        spamsource.example.com
    ipsec auto --rereadgroups
    [root@xy root]# cd /etc/ipsec.d/policies
+    [root@xy policies]# cat private
+        192.0.2.9              # several hosts at example.com
+        192.0.2.11             
+        192.0.2.12                 
+        irc.private.example.com 
+
    scp2 /etc/ipsec.d/policies/private root@192.0.2.12:/etc/ipsec.d/policies/private
    ipsec auto --rereadgroups
    ipsec eroute
    192.0.2.11/32   -> 192.0.2.8/32  => tun0x149f@192.0.2.8
+conn private-net
+    also=private  # inherits settings (eg. auto=start) from built in conn
+    leftsubnet=192.0.2.128/29  # your subnet's IPs here
+
+conn private-or-clear-net
+    also=private-or-clear
+    leftsubnet=192.0.2.128/29
+
+conn clear-or-private-net
+    also=clear-or-private
+    leftsubnet=192.0.2.128/29
+
+conn clear-net
+    also=clear
+    leftsubnet=192.0.2.128/29
+
+conn block-net
+    also=block
+    leftsubnet=192.0.2.128/29
+
+    cp -p /etc/ipsec.d/policies/private /etc/ipsec.d/policies/private-net
+    cp -p /etc/ipsec.d/policies/private-or-clear /etc/ipsec.d/policies/private-or-clear-net
+    cp -p /etc/ipsec.d/policies/clear-or-private /etc/ipsec.d/policies/clear-or-private-net
+    cp -p /etc/ipsec.d/policies/clear /etc/ipsec.d/policies/clear-net
+    cp -p /etc/ipsec.d/policies/block /etc/ipsec.d/policies/block
+
    ipsec eroute
    192.0.2.131/32   -> 192.139.46.77/32  => tun0x149f@192.0.2.11
    [root@xy root]# cd /etc/ipsec.d/policies
+    [root@xy policies]# cat private
+        192.0.2.9              # several hosts at example.com
+        192.0.2.11
+        192.0.2.12             # HR department gateway
+        192.0.2.192/29         # HR subnet
+        irc.private.example.com
+
    ipsec auto --rereadgroups
    [root@192.0.2.194]# ping 192.0.2.11
    ipsec eroute
    192.0.2.11/32   -> 192.0.2.194/32  => tun0x149f@192.0.2.12
+
conn block
+    auto=ignore
+
+conn private
+    auto=ignore
+
+conn private-or-clear
+    auto=ignore
+
+conn clear-or-private
+    auto=ignore
+
+conn clear
+    auto=ignore
+
+conn packetdefault
+    auto=ignore
    ipsec setup restart
conn net-to-net
+    left=192.0.2.2           # you are here
+    right=192.0.2.8
+    rightsubnet=192.0.2.96/27
+    ....
+
| How can I reload config's without restarting all of pluto and klips?  I am using
+| FreeSWAN -> PGPNet in a medium sized production environment, and would like to be
+| able to add new connections ( i am using include config/* ) without dropping current
+| SA's.
+| 
+| Can this be done?
+| 
+| If not, are there plans to add this kind of feature?
+
+        ipsec auto --add whatever
+This will look in the usual place (/etc/ipsec.conf) for a conn named
+whatever and add it.
+
+If you added new secrets, you need to do
+        ipsec auto --rereadsecrets
+before Pluto needs to know those secrets.
+
+| I have looked (perhaps not thoroughly enough tho) to see how to do this:
+
+There may be more bits to look for, depending on what you are trying
+to do.
Subject: Double NAT and freeswan working :)
+   Date: Sun, 11 Mar 2001
+   From: Paul Wouters <paul@xtdnet.nl>
+
+Just to share my pleasure, and make an entry for people who are searching
+the net on how to do this. Here's the very simple solution to have a double
+NAT'ed network working with freeswan. (Not sure if this is old news, but I'm
+not on the list (too much spam) and I didn't read this in any HOWTO/FAQ/doc
+on the freeswan site yet (Sandy, put it in! :)
+
+10.0.0.0/24 --- 10.0.0.1 a.b.c.d  ---- a.b.c.e {internet} ----+
+                                                              |
+10.0.1.0/24 --- 10.0.1.1 f.g.h.i  ---- f.g.h.j {internet} ----+
+
+the goal is to have the first network do a VPN to the second one, yet also
+have NAT in place for connections not destinated for the other side of the
+NAT. Here the two Linux security gateways have one real IP number (cable
+modem, dialup, whatever.
+
+The problem with NAT is you don't want packets from 10.*.*.* to 10.*.*.*
+to be NAT'ed. While with Linux 2.2, you can't, with Linux 2.4 you can.
+
+(This has been tested and works for 2.4.2 with Freeswan snapshot2001mar8b)
+
+relevant parts of /etc/ipsec.conf:
+
+        left=f.g.h.i
+        leftsubnet=10.0.1.0/24
+        leftnexthop=f.g.h.j
+        leftfirewall=yes
+        leftid=@firewall.netone.nl
+        leftrsasigkey=0x0........
+        right=a.b.c.d
+        rightsubnet=10.0.0.0/24
+        rightnexthop=a.b.c.e
+        rightfirewall=yes
+        rightid=@firewall.nettwo.nl
+        rightrsasigkey=0x0......
+        # To authorize this connection, but not actually start it, at startup,
+        # uncomment this.
+        auto=add
+
+and now the real trick. Setup the NAT correctly on both sites:
+
+iptables -t nat -F
+iptables -t nat -A POSTROUTING -o eth0 -d \! 10.0.0.0/8 -j MASQUERADE
+
+This tells the NAT code to only do NAT for packets with destination other then
+10.* networks. note the backslash to mask the exclamation mark to protect it
+against the shell.
+
+Happy painting :)
+
+Paul
   uniqueids=no   
> Do QoS add to FreeS/WAN?
+> For example integrating DiffServ and FreeS/WAN?
+
+With a current version of FreeS/WAN, you will have to add hidetos=no to
+the config-setup section of your configuration file.  By default, the TOS
+field of tunnel packets is zeroed; with hidetos=no, it is copied from the
+packet inside.  (This is a modest security hole, which is why it is no
+longer the default.)
+
+DiffServ does not interact well with tunneling in general.  Ways of
+improving this are being studied.
conn default
+        keyingtries=3
+        keylife=30m
You ask how to determine whether a tunnel is redundant:
+
+> Can anybody explain the best way to determine this. Esp when a RW has
+> disconnected? I thought 'ipsec auto --status' might be one way.
+
+If a tunnel goes down from one end, Linux FreeS/WAN on the
+other end has no way of knowing this until it attempts to rekey.
+Once it tries to rekey and fails, it will 'know' that the tunnel is 
+down.
+
+Because it doesn't have a way of knowing the state until this point, 
+it will also not be able to tell you the state via ipsec auto --status.
+
+> However, comparing output from a working tunnel with that of one that
+> was closed 
+> did not show clearly show tunnel status.
+
+If your tunnel is down but not 'unrouted' (see man ipsec_auto), you
+should not be able to ping the opposite side of the tunnel. You can
+use this as an indicator of tunnel status.
+
+On a related note, you may be interested to know that as of 1.7, 
+redundant tunnels caused by RW disconnections are likely to be 
+less of a pain. From doc/CHANGES:
+
+    There is a new configuration parameter, uniqueids, to control a new Pluto
+    option:  when a new connection is negotiated with the same ID as an old
+    one, the old one is deleted immediately.  This should help eliminate
+    dangling Road Warrior connections when the same Road Warrior reconnects. 
+    It thus requires that IDs not be shared by hosts (a previously legal but
+    probably useless capability).  NOTE WELL:  the sample ipsec.conf now has
+    uniqueids=yes in its config-setup section.
+
+
+Cheers,
+
+Claudia
> 5. If the ISDN link goes down in between and is reestablished, the SAs
+> are still up but the eroute are deleted and the IPsec interface shows
+> garbage (with ifconfig)
+> 6. Only restarting IPsec will bring the VPN back online.
+
+This one is awkward to solve.  If the real interface that the IPsec
+interface is mounted on goes down, it takes most of the IPsec machinery
+down with it, and a restart is the only good way to recover. 
+
+The only really clean fix, right now, is to split the machines in two: 
+
+1. A minimal machine serves as the network router, and only it is aware
+that the link goes up and down. 
+
+2. The IPsec is done on a separate gateway machine, which thinks it has
+a permanent network connection, via the router.
+
+This is clumsy but it does work.  Trying to do both functions within a
+single machine is tricky.  There is a software package (diald) which will
+give the illusion of a permanent connection for demand-dialed modem
+connections; I don't know whether it's usable for ISDN, or whether it can
+be made to cooperate properly with FreeS/WAN. 
+
+Doing a restart each time the interface comes up *does* work, although it
+is a bit painful.  I did that with PPP when I was running on a modem link;
+it wasn't hard to arrange the PPP scripts to bring IPsec up and down at
+the right times.  (I'd meant to investigate diald but never found time.)
+
+In principle you don't need to do a complete restart on reconnect, but you
+do have to rebuild some things, and we have no nice clean way of doing
+only the necessary parts.
Subject: Re: linux-ipsec: IPsec and Dial Up Connections
+   Date: Wed, 22 Nov 2000
+   From: Andy Bradford <andyb@calderasystems.com>
+
+On Wed, 22 Nov 2000 19:47:11 +0100, Philip Reetz wrote:
+
+> Are there any ideas what might be the cause of the problem and any way
+> to work around it.
+> Any help is highly appreciated.
+
+On my laptop, when using ppp there is a ip-up script in /etc/ppp that 
+will be executed each time that the ppp interface is brought up.  
+Likewise there is an ip-down script that is called when it is taken 
+down.  You might consider custimzing those to stop and start FreeS/WAN 
+with each connection.  I believe that ISDN uses the same files, though 
+I could be wrong---there should be something similar though.
      subnet a.b.c.0/24
+             |
+      eth1 = a.b.c.1
+         gate1
+      eth0 = 192.0.2.8
+             |
+
+       ~ internet ~
+
+             |
+      eth0 = 192.0.2.11
+         gate2
+      eth1 = x.y.z.1
+              |
+       subnet x.y.z.0/24
conn abc-xyz
+     left=192.0.2.8
+     leftsubnet=a.b.c.0/24
+     right=192.0.2.11
+     rightsubnet=x.y.z.0/24
        ping -I a.b.c.1 x.y.z.1
> ... when i run /etc/rc.d/init.d/ipsec start, i get:
+> ipsec_setup: Starting FreeS/WAN IPsec 1.5...
+> and it just sits there, doesn't give back my bash prompt.
+
+Almost certainly, the problem is that you're using DNS names in your
+ipsec.conf, but DNS lookups are not working for some reason.  You will
+get your prompt back... eventually.  But the DNS timeouts are long.
+Doing something about this is on our list, but it is not easy.
Subject: Final Answer to Delay!!!
+   Date: Mon, 19 Feb 2001
+   From: "Felippe Solutions" <felippe@solutionstecnologia.com.br>
+
+Sorry people, but seems like the Delay problem had nothing to do with
+freeswan.
+
+The problem was DNS as some people sad from the beginning, but not the way
+they thought it was happening. Samba, ssh, telnet and other apps try to
+reverse lookup addresses when you use IP numbers (Stupid that ahh).
+
+I could ping very fast because I always ping with "-n" option, but I don't
+know the option on the other apps to stop reverse addressing so I don't use
+it.
         leftsubnet -- leftgateway === internet === roadwarrior
> > Packets vanishing between the hardware interface and the ipsecN interface
+> > is usually the result of firewalls not being configured to let them in...
+> 
+> Thanks for the suggestion. If only it were that simple! My ipchains startup
+> script does take care of that, but just in case I manually inserted rules 
+> accepting everything from london on dublin. No difference.
+
+The other thing to check is whether the "RX packets dropped" count on the
+ipsecN interface (run "ifconfig ipsecN", for N=1 or whatever, to see the
+counts) is rising.  If so, then there's some sort of configuration mismatch
+between the two ends, and IPsec itself is rejecting them.  If none of the
+ipsecN counts is rising, then the packets are never reaching the IPsec
+machinery, and the problem is almost certainly in firewalls etc.
+> After about 24 hours the freeswan connection takes over the default route.
+> 
+> i.e instead of deafult gateway pointing to the router via eth0, it becomes a 
+> pointer to the router via ipsec0.
+ 
+> All internet access is then lost as all replies (and not just the link I 
+> wanted) are routed out ipsec0 and the router doesn't respond to the ipsec 
+> traffic.
+
    ipsec tnconfig --attach --virtual ipsec0 --physical ppp0
Date: Mon, 14 May 2001
+To: linux-ipsec@freeswan.org
+From: "John S. Denker" <jsd@research.att.com<
+Subject: Re: traceroute: one virtual hop
+
+At 02:20 PM 5/14/01 -0400, Claudia Schmeing wrote:
+>
+>> > A bonus question: traceroute in subnet to subnet enviroment looks like:
+>> > 
+>> > traceroute to andris.dmz (172.20.24.10), 30 hops max, 38 byte packets
+>> > 1  drama (172.20.1.1)  0.716 ms  0.942 ms  0.434 ms
+>> > 2  * * *
+>> > 3  andris.dmz (172.20.24.10)  73.576 ms  78.858 ms  79.434 ms
+>> > 
+>> > Why aren't there the other hosts which take part in the delivery during 
+>    * * * ?
+>
+>If there is an ipsec tunnel between GateA and Gate B, this tunnel forms a 
+>'virtual wire'.  When it is tunneled, the original packet becomes an inner 
+>packet, and new ESP and/or AH headers are added to create an outer packet 
+>around it. You can see an example of how this is done for AH at 
+>doc/ipsec.html#AH . For ESP it is similar.
+>
+>Think about the packet's path from the inner packet's perspective.
+>It leaves the subnet, goes into the tunnel, and re-emerges in the second
+>subnet. This perspective is also the only one available to the
+>'traceroute' command when the IPSec tunnel is up.
+
+Claudia got this exactly right.  Let me just expand on a couple of points:
+
+*) GateB is exactly one (virtual) hop away from GateA.  This is how it
+would be if there were a physically private wire from A to B.  The
+virtually private connection should work the same, and it does.
+
+*) While the information is in transit from GateA to GateB, the hop count
+of the outer header (the "envelope") is being decremented.  The hop count
+of the inner header (the "contents" of the envelope) is not decremented and
+should not be decremented.  The hop count of the outer header is not
+derived from and should not be derived from the hop count of the inner header.
+
+Indeed, even if the packets did time out in transit along the tunnel, there
+would be no way for traceroute to find out what happened.  Just as
+information cannot leak _out_ of the tunnel to the outside, information
+cannot leak _into_ the tunnel from outside, and this includes ICMP messages
+from routers along the path.
+
+There are some cases where one might wish for information about what is
+happening at the IP layer (below the tunnel layer) -- but the protocol
+makes no provision for this.  This raises all sorts of conceptual issues.
+AFAIK nobody has ever cared enough to really figure out what _should_
+happen, let alone implement it and standardize it.
+
+*) I consider the "* * *" to be a slight bug.  One might wish for it to be
+replaced by "GateB GateB GateB".  It has to do with treating host-to-subnet
+traffic different from subnet-to-subnet traffic (and other gory details).
+I fervently hope KLIPS2 will make this problem go away.
+
+*) If you want to ask questions about the link from GateA to GateB at the
+IP level (below the tunnel level), you have to ssh to GateA and launch a
+traceroute from there.
> ipsec_sha1.c: In function `SHA1Transform':
+> ipsec_sha1.c:95: virtual memory exhausted
+
+I'm seeing exactly the same problem on an Ultra with 256MB ram and 500
+MB swap.  Except I am compiling version 1.5 and its Red Hat 6.2.
+
+I can get around this by using -O instead of -O2 for the optimization
+level.  So it is probably a bug in the optimizer on the sparc complier. 
+I'll try and chase this down on the sparc lists.
> I reached the point where the two boxes (both on dial-up connections, but
+> treated as static IPs by getting the IP and editing ipsec.conf after the
+> connection is established) to the point where they exchange some info, but I
+> get an error like "route-client command exited with status 7 \n internal
+> error".
+> Where can I find a description of this error?
+
+In general, if the FAQ doesn't cover it, you can search the mailing list 
+archives - I like to use
+http://www.sandelman.ottawa.on.ca/linux-ipsec/
+but you can see doc/mail.html for different archive formats.
+
+
+Your error comes from the _updown script, which performs some
+routing and firewall functions to help Linux FreeS/WAN. More info
+is available at doc/firewall.html and man ipsec.conf. Its routing
+is integral to the health of Linux FreeS/WAN; it also provides facility
+to insert custom firewall rules to be executed when you create or destroy
+a connection.
+
+Yours is, of course, a routing error. You can be fairly sure the routing 
+machinery is saying "network is unreachable". There's a FAQ on the 
+"network is unreachable" error, but more information is available now; read on.
+
+If your _updown script is recent (for example if it shipped with 
+Linux FreeS/WAN 1.91), you will see another debugging line in your logs 
+that looks something like this:
+
+> output: /usr/local/lib/ipsec/_updown: `route add -net 128.174.253.83 
+> netmask 255.255.255.255 dev ipsec0 gw 66.92.93.161' failed
+
+This is, of course, the system route command that exited with status 7, 
+(ie. failed). Man route for details. Seeing the command typed out yields 
+more information. If your _updown script is older, you may wish to update 
+it to show the command explicitly.
+
+Three parameters fed to the route command: net, netmask and gw [gateway] 
+are derived from things you've put in ipsec.conf.
+
+Net and netmask are derived from the peer's IP and mask. In more detail:
+
+You may see a routing error when routing to a client (ie. subnet), or 
+to a host (IPSec gateway or freestanding host; a box that does IPSec for
+itself). In _updown, the "route-client" section  is responsible to set up 
+the route for IPSec'd (usually, read 'tunneled') packets headed to a 
+peer subnet. Similarly, route-host routes IPSec'd packets to a peer host
+or IPSec gateway.
+
+When routing to a 'client', net and netmask are ipsec.conf's left- or 
+rightsubnet (whichever is not local). Similarly, when routing to a 
+'host' the net is left or right. Host netmask is always /32, indicating a 
+single machine.
+
+Gw is nexthop's value. Again, the value in question is left- or rightnexthop,
+whichever is local. Where left/right or left-/rightnexthop has the special 
+value %defaultroute (described in man ipsec.conf), gw will automagically get
+the value of the next hop on the default route.
+
+Q: "What's a nexthop and why do I need one?"
+
+A: 'nexthop' is a routing kluge; its value is the next hop away
+   from the machine that's doing IPSec, and toward your IPSec peer. 
+   You need it to get the processed packets out of the local system and 
+   onto the wire. While we often route other packets through the machine 
+   that's now doing IPSec, and are done with it, this does not suffice here. 
+   After packets are processed with IPSec, this machine needs to know where 
+   they go next. Of course using the 'IPSec gateway' as their routing gateway 
+   would cause an infinite loop! [To visualize this, see the packet flow 
+   diagram at doc/firewall.html.] To avoid this, we route packets through 
+   the next hop down their projected path.
+
+Now that you know the background, consider:
+1. Did you test routing between the gateways in the absence of Linux
+   FreeS/WAN, as recommended? You need to ensure the two machines that
+   will be running Linux FreeS/WAN can route to one another before trying to 
+   make a secure connection.
+2. Is there anything obviously wrong with the sense of your route command?
+
+Normally, this problem is caused by an incorrect local nexthop parameter.
+Check out the use of %defaultroute, described in man ipsec.conf. This is
+a simple way to set nexthop for most people. To figure nexthop out by hand,
+traceroute in-the-clear to your IPSec peer. Nexthop is the traceroute's 
+first hop after your IPSec gateway.
You write,
+> I have correctly installed freeswan-1.8 on RH7.0 kernel 2.2.17, but when 
+> I setup a VPN connection with the other machine(RH5.2 Kernel 2.0.36 
+> freeswan-1.0, it works well.) it told me that 
+> "SIOCADDRT:Network is unreachable"!  But the network connection is no 
+> problem.
+
+Often this error is the result of a misconfiguration. 
+
+Be sure that you can route successfully in the absence of Linux
+FreeS/WAN. (You say this is no problem, so proceed to the next step.)
+
+Use a custom copy of the default updownscript. Do not change the route 
+commands, but add a diagnostic message revealing the exact text of the 
+route command. Is there a problem with the sense of the route command
+that you can see? If so, then re-examine those ipsec.conf settings
+that are being sent to the route command. 
+
+You may wish to use the ipsec auto --route and --unroute commands to 
+troubleshoot the problem. See man ipsec_auto for details.
> I tried to install freeswan 1.8 on my mandrake 7.2 test box. ...
+
+> It does show version and some output for whack.
+
+Yes, because the Pluto (daemon) part of ipsec is installed correctly, but
+as we see below the kernel portion is not.
+
+> However, I get the following from /var/log/messages:
+> 
+> Mar 11 22:11:55 pavillion ipsec_setup: Starting FreeS/WAN IPsec 1.8...
+> Mar 11 22:12:02 pavillion ipsec_setup: modprobe: Can't locate module ipsec
+> Mar 11 22:12:02 pavillion ipsec_setup: Fatal error, kernel appears to lack
+> KLIPS.
+
+This is your problem. You have not successfully installed a kernel with
+IPSec machinery in it. 
+
+Did you build Linux FreeS/WAN as a module? If so, you need to ensure that 
+your new module has been installed in the directory where your kernel 
+loader normally finds your modules. If not, you need to ensure
+that the new IPSec-enabled kernel is being loaded correctly.
+
+See also doc/install.html, and INSTALL in the distro.
Note that by default, FreeS/WAN is now set up to
+     (a) authenticate with RSA keys, and
+     (b) fetch the public key of the far end from DNS.
+Explicit attention to  ipsec.conf will be needed if you want
+to do something different.
You write,
+
+>       My current setup in ipsec.conf is leftrsasigkey=%dns I have 
+> commented this and authby=rsasig out. I am able to get ipsec running, 
+> but what I find is that the documentation only specifies for %dns are 
+> there any other values that can be placed in this variable other than 
+> %dns and the key? I am also assuming that this is where I would place 
+> my public key for the left and right side as well is this correct?
+
+Valid values for authby= are rsasig and secret, which entail authentication
+by RSA signature or by shared secret, respectively. Because you have 
+commented authby=rsasig out, you are using the default value of authby=secret. 
+
+When using RSA signatures, there are two ways to get the public key for the
+IPSec peer: either copy it directly into *rsasigkey= in ipsec.conf, or
+fetch it from dns. The magic value %dns for *rsasigkey parameters says to 
+try to fetch the peer's key from dns.
+
+For any parameters, you may find their significance and special values in
+man ipsec.conf. If you are setting up keys or secrets, be sure also to
+reference man ipsec.secrets.
| I'm trying to get freeswan working between two machine where one has a ppp
+| interface.
+| I've already suceeded with  two machines with ethernet ports but  the ppp
+| interface is causing me problems.
+|  basically when I run ipsec start  i get
+| ipsec_setup: Starting FreeS/WAN IPsec 1.7...
+| ipsec_setup: 003 IP interfaces ppp1 and ppp0 share address 192.168.0.10!
+| ipsec_setup: 003 IP interfaces ppp1 and ppp2 share address 192.168.0.10!
+| ipsec_setup: 003 IP interfaces ppp0 and ppp2 share address 192.168.0.10!
+| ipsec_setup: 003 no public interfaces found
+|
+| followed by lots of cannot work out interface for connection messages
+|
+| now I can specify the interface in ipsec.conf to be ppp0 , but this does
+| not affect the above behaviour. A quick look in server.c indicates that the
+| interfaces value  is not used but some sort of raw detect happens.
+|
+| I guess I could prevent the formation of the extra ppp interfaces or
+| allocate them different ip but I'd  rather not. if at all possible. Any
+| suggestions please.
+
+Pluto won't touch an interface that shares an IP address with another.
+This will eventually change, but it probably won't happen soon.
+
+For now, you will have to give the ppp1 and ppp2 different addresses.
> When FreeS/WAN IPsec 1.7 is starting on my 2.0.38 Linux kernel the following
+> error message is generated:
+> ipsec_setup: Cannot adjust kernel flags, no /proc/sys/net/ipsec directory!
+> What is supposed to create this directory and how can I fix this problem?
+
+I think that directory is a 2.2ism, although I'm not certain (I don't have
+a 2.0.xx system handy any more for testing).  Without it, some of the
+ipsec.conf config-setup flags won't work, but otherwise things should
+function. 
| Jan 17 16:21:10 remus Pluto[13631]: "jumble" #1: responding to Main Mode from Road Warrior 130.205.82.46
+| Jan 17 16:21:11 remus Pluto[13631]: "jumble" #1: no suitable connection for peer @banshee.wittsend.com
+| 
+|     The connection "jumble" has nothing to do with the incoming
+| connection requests, which were meant for the connection "banshee".
+
+You are right.  The message tells you which Connection Pluto is
+currently using, which need not be the right one.  It need not be the
+right one now for the negotiation to eventually succeed!  This is
+described in ipsec_pluto(8) in the section "Road Warrior Support".
+
+There are two times when Pluto will consider switching Connections for
+a state object.  Both are in response to receiving ID payloads (one in
+Phase 1 / Main Mode and one in Phase 2 / Quick Mode).  The second is
+not unique to Road Warriors.  In fact, neither is the first any more
+(two connections for the same pair of hosts could differ in Phase 1 ID
+payload; probably nobody else has tried this).
| Jul 12 15:00:22 sohar58 Pluto[574]: "corp_road" #2: cannot respond to IPsec
+| SA request because no connection is known for
+| 216.112.83.112/32===216.112.83.112...216.67.25.118
+
+This is the first message from the Pluto log showing a problem.  It
+means that PGPnet is trying to negotiate a set of SAs with this
+topology:
+
+216.112.83.112/32===216.112.83.112...216.67.25.118
+^^^^^^^^^^^^^^^^^   ^^^^^^^^^^^^^^   ^^^^^^^^^^^^^
+client on our side  our host         PGPnet host, no client
+
+None of the conns you showed look like this.
+
+Use
+        ipsec auto --status
+to see a snapshot of what connections are in pluto, what
+negotiations are going on, and what SAs are established.
+
+The leftsubnet= (client) in your conn is 216.112.83.64/26.  It must
+exactly match what pluto is looking for, and it does not.
You write,
+
+> What could be the reason of the following error? 
+> "no suitable connection for peer '@xforce'"
+
+When a connection is initiated by the peer, Pluto must choose which entry in 
+the conf file best matches the incoming connection. A preliminary choice is 
+made on the basis of source and destination IPs, since that information is 
+available at that time. 
+
+A payload containing an ID arrives later in the negotiation. Based on this
+id and the *id= parameters, Pluto refines its conn selection. ...
+
+The message "no suitable connection" indicates that in this refining step,
+Pluto does not find a connection that matches that ID.
+
+Please see "Selecting a connection when responding" in man ipsec_pluto for
+more details.
You write,
+
+>  May 22 10:46:31 debian Pluto[25834]: packet from x.y.z.p:10014: 
+>  initial Main Mode message from x.y.z.p:10014 
+                            but no connection has been authorized
+
+This error occurs early in the connection negotiation process,
+at the first step of IKE negotiation (Main Mode), which is itself the 
+first of two negotiation phases involved in creating an IPSec connection.
+
+Here, Linux FreeS/WAN receives a packet from a potential peer, which 
+requests that they begin discussing a connection.
+
+The "no connection has been authorized" means that there is no connection 
+description in Linux FreeS/WAN's internal database that can be used to 
+link your ipsec interface with that peer.
+
+"But of course I configured that connection!" 
+
+It may be that the appropriate connection description exists in ipsec.conf 
+but has not been added to the database with ipsec auto --add myconn or the 
+auto=add method. Or, the connection description may be misconfigured.
+
+The only parameters that are relevant in this decision are left= and right= .
+Local and remote ports are also taken into account -- we see that the port 
+is printed in the message above -- but there is no way to control these
+in ipsec.conf.
+
+
+Failure at "no connection has been authorized" is similar to the
+"no connection is known for..." error in the FAQ, and the "no suitable
+connection" error described in the snapshot's FAQ. In all three cases,
+Linux FreeS/WAN is trying to match parameters received in the
+negotiation with the connection description in the local config file.
+
+As it receives more information, its matches take more parameters into 
+account, and become more precise:  first the pair of potential peers,
+then the peer IDs, then the endpoints (including any subnets).
+
+The "no suitable connection for peer *" occurs toward the end of IKE 
+(Main Mode) negotiation, when the IDs are matched.
+
+"no connection is known for a/b===c...d" is seen at the beginning of IPSec 
+(Quick Mode, phase 2) negotiation, when the connections are matched using
+left, right, and any information about the subnets.
Background:
+
+When one IKE system (for example, Pluto) is negotiating with another
+to create an SA, the Initiator proposes a bunch of choices and the
+Responder replies with one that it has selected.
+
+The structure of the choices is fairly complicated.  An SA payload
+contains a list of lists of "Proposals".  The outer list is a set of
+choices: the selection must be from one element of this list.
+
+Each of these elements is a list of Proposals.  A selection must be
+made from each of the elements of the inner list.  In other words,
+*all* of them apply (that is how, for example, both AH and ESP can
+apply at once).
+
+Within each of these Proposals is a list of Transforms.  For each
+Proposal selected, one Transform must be selected (in other words,
+each Proposal provides a choice of Transforms).
+
+Each Transform is made up of a list of Attributes describing, well,
+attributes.  Such as lifetime of the SA.  Such as algorithm to be
+used.  All the Attributes apply to a Transform.
+
+You will have noticed a pattern here: layers alternate between being
+disjunctions ("or") and conjunctions ("and").
+
+For Phase 1 / Main Mode (negotiating an ISAKMP SA), this structure is
+cut back.  There must be exactly one Proposal.  So this degenerates to
+a list of Transforms, one of which must be chosen.
+
+In your case, no proposal was considered acceptable to Pluto (the
+Responder).  So negotiation ceased.  Pluto logs the reason it rejects
+each Transform.  So look back in the log to see what is going wrong.
On Fri, 29 Jun 2001, Rodrigo Gruppelli wrote:
+> ...Well, it seem that there's
+> another problem with it. When I try to generate a pair of RSA keys,
+> rsasigkey cores dump...
+
+*That* is a neon sign flashing "GMP LIBRARY IS BROKEN".  Rsasigkey calls
+GMP a lot, and our own library a little bit, and that's very nearly all it
+does.  Barring bugs in its code or our library -- which have happened, but
+not very often -- a problem in rsasigkey is a problem in GMP.
1)  The log message
+  some IKE message we sent has been rejected with 
+  ECONNREFUSED (kernel supplied no details)
+is much more suitable than the previous version.  Thanks.
+
+2) Minor suggestion for further improvement: it might be worth mentioning
+that the command
+  tcpdump -i eth1 icmp[0] != 8 and icmp[0] != 0
+is useful for tracking down the details in question.  We shouldn't expect
+all IPsec users to figure that out on their own.  The log message might
+even provide a hint as to where to look in the docs.
Good idea.
+
+I've added a bit pluto(8)'s BUGS section along these lines.
+I didn't have the heart to lengthen this message.
> Why ipsec reports no eroute! ???? IP Masq... is disabled.
+
+In general, more information is required so that people on the list may
+give you informed input. See doc/prob.report.
However, I can make some general comments on this type of error.
+
+This error usually looks something like this (clipped from an archived
+message):
+
+> ttl:64 proto:1 chk:45459 saddr:192.168.1.2 daddr:192.168.100.1
+> ... klips_debug:ipsec_findroute: 192.168.1.2->192.168.100.1
+> ... klips_debug:rj_match: * See if we match exactly as a host destination
+> ... klips_debug:rj_match: ** try to match a leaf, t=0xc1a260b0
+> ... klips_debug:rj_match: *** start searching up the tree, t=0xc1a260b0
+> ... klips_debug:rj_match: **** t=0xc1a260c8
+> ... klips_debug:rj_match: **** t=0xc1fe5960
+> ... klips_debug:rj_match: ***** not found.
+> ... klips_debug:ipsec_tunnel_start_xmit: Original head/tailroom: 2, 28
+> ... klips_debug:ipsec_tunnel_start_xmit: no eroute!: ts=47.3030, dropping.
+
+
+What does this mean?
+- --------------------
+
+"eroute" stands for "extended route", and is a special type of route 
+internal to Linux FreeS/WAN. For more information about this type of route, 
+see the section of man ipsec_auto on ipsec auto --route.
+
+"no eroute!" here means, roughly, that Linux FreeS/WAN cannot find an 
+appropriate tunnel that should have delivered this packet. Linux 
+FreeS/WAN therefore drops the packet, with the message "no eroute! ...
+dropping", on the assumption that this packet is not a legitimate 
+transmission through a properly constructed tunnel.
+
+
+How does this situation come about?
+- -----------------------------------
+
+Linux FreeS/WAN has a number of connection descriptions defined in 
+ipsec.conf. These must be successfully brought "up" to form actual tunnels.
+(see doc/setup.html's step 15, man ipsec.conf and man ipsec_auto 
+for details).
+
+Such connections are often specific to the endpoints' IPs. However, in 
+some cases they may be more general, for example in the case of 
+Road Warriors where left or right is the special value %any.
+
+When Linux FreeS/WAN receives a packet, it verifies that the packet has
+come through a legitimate channel, by checking that there is an
+appropriate tunnel through which this packet might legitimately have
+arrived. This is the process we see above.
+
+First, it checks for an eroute that exactly matches the packet. In the 
+example above, we see it checking for a route that begins at 192.168.1.2
+and ends at 192.168.100.1. This search favours the most specific match that
+would apply to the route between these IPs. So, if there is a connection 
+description exactly matching these IPs, the search will end there. If not, 
+the code will search for a more general description matching the IPs.
+If there is no match, either specific or general, the packet will be
+dropped, as we see, above.
+
+Unless you are working with Road Warriors, only the first, specific part 
+of the matching process is likely to be relevant to you.
+
+
+"But I defined the tunnel, and it came up, why do I have this error?"
+- ---------------------------------------------------------------------
+
+One of the most common causes of this error is failure to specify enough
+connection descriptions to cover all needed tunnels between any two 
+gateways and their respective subnets. As you have noticed, troubleshooting
+this error may be complicated by the use of IP Masq. However, this error is
+not limited to cases where IP Masq is used. 
+
+See doc/configuration.html#multitunnel for a detailed example of the 
+solution to this type of problem.
On Mon, 15 Jan 2001, Jay Vaughan wrote:
+> I know I'm flogging a dead horse here, but I'm curious as to the reasons for
+> an aversion for a subscriber-only mailing list?
+
+Once again:  for legal reasons, it is important that discussions of these
+things be held in a public place -- the list -- and we do not want to
+force people to subscribe to the list just to ask one question, because
+that may be more than merely inconvenient for them.  There are also real
+difficulties with people who are temporarily forced to use alternate
+addresses; that is precisely the time when they may be most in need of
+help, yet a subscribers-only policy shuts them out.
+
+These issues do not apply to most mailing lists, but for a list that is
+(necessarily) the primary user support route for a crypto package, they
+are very important.  This is *not* an ordinary mailing list; it has to
+function under awkward constraints that make various simplistic solutions
+inapplicable or undesirable. 
+
+> We're *ALL* sick of hearing about list management problems, not just you
+> old-timers, so why don't you DO SOMETHING EFFECTIVE ABOUT IT...
+
+Because it's a lot harder than it looks, and many existing "solutions"
+have problems when examined closely.
+
+> A suggestion for you, based on 10 years of experience with management of my
+> own mailing lists would be to use mailman, which includes pretty much every
+> feature under the sun that you guys need and want, plus some.  The URL for
+> mailman...
+
+I assure you, we're aware of mailman.  Along with a whole bunch of others,
+including some you almost certainly have never heard of (I hadn't!).
+
+> As for the argument that the list shouldn't be configured to enforce
+> subscription - I contend that it *SHOULD* AT LEAST require manual address
+> verification in order for posts to be redirected.
+
+You do realize, I hope, that interposing such a manual step might cause
+your government to decide that this is not truly a public forum, and thus
+you could go to jail if you don't get approval from them before mailing to
+it?  If you think this sounds irrational, your government is noted for
+making irrational decisions in this area; we can't assume that they will
+suddenly start being sensible.  See above about awkward constraints.  You
+may be willing to take the risk, but we can't, in good conscience, insist
+that all users with problems do so. 
+
+                                                          Henry Spencer
+                                                       henry@spsystems.net
Subject: Re: The linux-ipsec list's topic
+   Date: Sat, 30 Dec 2000
+   From: John Gilmore <gnu@toad.com>
+
+I'll post this single message, once only, in this discussion, and then
+not burden the list with any further off-topic messages.  I encourage
+everyone on the list to restrain themself from posting ANY off-topic
+messages to the linux-ipsec list.
+
+The topic of the linux-ipsec mailing list is the FreeS/WAN software.
+
+I frequently see "discussions about spam on a list" overwhelm the
+volume of "actual spam" on a list. BOTH kinds of messages are
+off-topic messages.  Twenty anti-spam messages take just as long to
+detect and discard as twenty spam messages.
+
+The Linux-ipsec list encourages on-topic messages from people who have
+not joined the list itself.  We will not censor messages to the list
+based on where they originate, or what return address they contain.
+In other words, non-subscribers ARE allowed to post, and this will not
+change.  My own valid contributions have been rejected out-of-hand by
+too many other mailing lists for me to want to impose that censorship
+on anybody else's contributions.  And every day I see the damage that
+anti-spam zeal is causing in many other ways; that zeal is far more
+damaging to the culture of the Internet than the nuisance of spam.
+
+In general, it is the responsibility of recipients to filter,
+prioritize, or otherwise manage the handling of email that comes to
+them.  It is not the responsibility of the rest of the Internet
+community to refrain from sending messages to recipients that they
+might not want to see.  If your software infrastructure for managing
+your incoming email is insufficient, then improve it.  If you think
+the signal-to-noise ratio on linux-ipsec is too poor, then please
+unsubscribe.  But don't further increase the noise by posting to the
+linux-ipsec list about those topics.
+
+        John Gilmore
+        founder & sponsor, FreeS/WAN project
du /usr > /dev/null &
# allow IPsec
+#
+# IKE negotiations
+iptables -I INPUT  -p udp --sport 500 --dport 500 -j ACCEPT
+iptables -I OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT
+# ESP encryption and authentication
+iptables -I INPUT  -p 50 -j ACCEPT
+iptables -I OUTPUT -p 50 -j ACCEPT
+
service iptables save
Most people just have a single PPP connection to the Internet, and don't
+want anyone coming back into their network, or the firewall:
+
+    ## Insert connection-tracking modules (not needed if built into kernel).
+    # insmod ip_conntrack
+    # insmod ip_conntrack_ftp
+
+    ## Create chain which blocks new connections, except if coming from inside.
+    # iptables -N block
+    # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
+    # iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
+    # iptables -A block -j DROP
+
+    ## Jump to that chain from INPUT and FORWARD chains.
+    # iptables -A INPUT -j block
+    # iptables -A FORWARD -j block
    ## Create chain which blocks new connections, except if coming from inside.
+    # iptables -N block
+    # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
+    # iptables -A block -m state --state NEW -i ppp+ -j DROP
+    # iptables -A block -m state --state NEW -i ipsec+ -j DROP
+    # iptables -A block -m state --state NEW -i -j ACCEPT
+    # iptables -A block -j DROP
      clients --- NAT ----- SG ---------- SG
+                  two machines
      clients ----- NAT/SG ---------------SG
+                  one machine
      clients --- SG --- NAT ---------- SG
     Sunset==========West------------------East ================= firewall --- the Internet
+         home network      untrusted net        corporate network
# ICMP types which lack socially redeeming value.
+#  5     Redirect
+#  9     Router Advertisement
+# 10     Router Selection
+# 15     Information Request
+# 16     Information Reply
+# 17     Address Mask Request
+# 18     Address Mask Reply
+
+badicmp='5 9 10 15 16 17 18'
There are many important things left out
+
+- firewalling is important but must reflect (implement) policy.  Since
+  policy isn't the same for all our customers, and we're not experts,
+  we should concentrate on FW and MASQ interactions with FreeS/WAN.
+
+- we need a diagram to show packet flow WITHIN ONE MACHINE, assuming
+  IKE, IPsec, FW, and MASQ are all done on that machine.  The flow is
+  obvious if the components are run on different machines (trace the
+  cables).
+
+  IKE input:
+        + packet appears on public IF, as UDP port 500
+        + input firewalling rules are applied (may discard)
+        + Pluto sees the packet.
+
+  IKE output:
+        + Pluto generates the packet & writes to public IF, UDP port 500
+        + output firewalling rules are applied (may discard)
+        + packet sent out public IF
+
+  IPsec input, with encapsulated packet, outer destination of this host:
+        + packet appears on public IF, protocol 50 or 51.  If this
+          packet is the result of decapsulation, it will appear
+          instead on the paired ipsec IF.
+        + input firewalling rules are applied (but packet is opaque)
+        + KLIPS decapsulates it, writes result to paired ipsec IF
+        + input firewalling rules are applied to resulting packet
+          as input on ipsec IF
+        + if the destination of the packet is this machine, the
+          packet is passed on to the appropriate protocol handler.
+          If the original packet was encapsulated more than once
+          and the new outer destination is this machine, that
+          handler will be KLIPS.
+        + otherwise:
+          * routing is done for the resulting packet.  This may well
+            direct it into KLIPS for encoding or encrypting.  What
+            happens then is described elsewhere.
+          * forwarding firewalling rules are applied
+          * output firewalling rules are applied
+          * the packet is sent where routing specified
+
+ IPsec input, with encapsulated packet, outer destination of another host:
+        + packet appears on some IF, protocol 50 or 51
+        + input firewalling rules are applied (but packet is opaque)
+        + routing selects where to send the packet
+        + forwarding firewalling rules are applied (but packet is opaque)
+        + packet forwarded, still encapsulated
+
+  IPsec output, from this host or from a client:
+        + if from a client, input firewalling rules are applied as the
+          packet arrives on the private IF
+        + routing directs the packet to an ipsec IF (this is how the
+          system decides KLIPS processing is required)
+        + if from a client, forwarding firewalling rules are applied
+        + KLIPS eroute mechanism matches the source and destination
+          to registered eroutes, yielding a SPI group.  This dictates
+          processing, and where the resulting packet is to be sent
+          (the destinations SG and the nexthop).
+        + output firewalling is not applied to the resulting
+          encapsulated packet
+
+- Until quite recently, KLIPS would double encapsulate packets that
+  didn't strictly need to be.  Firewalling should be prepared for
+  those packets showing up as ESP and AH protocol input packets on
+  an ipsec IF.
+
+- MASQ processing seems to be done as if it were part of the
+  forwarding firewall processing (this should be verified).
+
+- If a firewall is being used, it is likely the case that it needs to
+  be adjusted whenever IPsec SAs are added or removed.  Pluto invokes
+  a script to do this (and to adjust routing) at suitable times.  The
+  default script is only suitable for ipfwadm-managed firewalls.  Under
+  LINUX 2.2.x kernels, ipchains can be managed by ipfwadm (emulation),
+  but ipchains more powerful if manipulated using the ipchains command.
+  In this case, a custom updown script must be used.
+
+  We think that the flexibility of ipchains precludes us supplying an
+  updown script that would be widely appropriate.
    freeswan-userland-2.04_2.4.20_20.9-0.i386.rpm
+    freeswan-module-2.04_2.4.20_20.9-0.i386.rpm
+
service ipsec start
no RSA public key known for '192.0.2.13';
+DNS search for KEY failed (no KEY record
+for 13.2.0.192.in-addr.arpa.)
ipsec auto --rereadgroups
Can't Opportunistically initiate for
+192.0.2.2 to 192.0.2.3: no TXT record
+for 13.2.0.192.in-addr.arpa.
...
+Looking for TXT in forward map:
+                xy.example.com...[FAILED]
+Looking for TXT in reverse map...[FAILED]
+...
Possible authentication failure:
+no acceptable response to our
+first encrypted message
ipsec auto --rereadgroups
/etc/ipsec.d/policies/iprivate-or-clear"
+line 14: subnet "0.0.0.0/0",
+source 192.0.2.13/32,
+already "private-or-clear"
grep -F 0.0.0.0/0 /etc/ipsec.d/policies/*
ipsec auto --status
    000 #21: "myconn" STATE_MAIN_I4 (ISAKMP SA established)...
+    000 #2: "myconn" STATE_QUICK_I2 (sent QI2, IPsec SA established)...
    ipsec auto --verbose --up west-east
+    ipsec barf > barf.west
+
klipsdebug... no eroute
    iptables -L -n -v
     Sunset==========West------------------East=========Sunrise
+                     IPSec gateway         IPSec gateway
+           local net       untrusted net       local net
Here is a catalogue of the types of errors that can occur for which
+statistics are kept when transmitting and receiving packets via klips.
+I notice that they are not necessarily logged in the right counter.
+. . .
+
+Sources of ifconfig statistics for ipsec devices
+
+rx-errors:
+- packet handed to ipsec_rcv that is not an ipsec packet.
+- ipsec packet with payload length not modulo 4.
+- ipsec packet with bad authenticator length.
+- incoming packet with no SA.
+- replayed packet.
+- incoming authentication failed.
+- got esp packet with length not modulo 8.
+
+tx_dropped:
+- cannot process ip_options.
+- packet ttl expired.
+- packet with no eroute.
+- eroute with no SA.
+- cannot allocate sk_buff.
+- cannot allocate kernel memory.
+- sk_buff internal error.
+
+
+The standard counters are:
+
+struct enet_statistics
+{
+        int        rx_packets;                /* total packets received */
+        int        tx_packets;                /* total packets transmitted */
+        int        rx_errors;                /* bad packets received */
+        int        tx_errors;                /* packet transmit problems */
+        int        rx_dropped;                /* no space in linux buffers */
+        int        tx_dropped;                /* no space available in linux */
+        int        multicast;                /* multicast packets received */
+        int        collisions;
+
+        /* detailed rx_errors: */
+        int        rx_length_errors;
+        int        rx_over_errors;                /* receiver ring buff overflow */
+        int        rx_crc_errors;                /* recved pkt with crc error */
+        int        rx_frame_errors;        /* recv'd frame alignment error */
+        int        rx_fifo_errors;                /* recv'r fifo overrun */
+        int        rx_missed_errors;        /* receiver missed packet */
+
+        /* detailed tx_errors */
+        int        tx_aborted_errors;
+        int        tx_carrier_errors;
+        int        tx_fifo_errors;
+        int        tx_heartbeat_errors;
+        int        tx_window_errors;
+};
+
+of which I think only the first 6 are useful.
Can you get a core dump and use gdb to find out what Pluto was doing
+when it died?
+
+To get a core dump, you will have to set dumpdir to point to a
+suitable directory (see ipsec.conf(5)).
+
+To get gdb to tell you interesting stuff:
+        $ script
+        $ cd dump-directory-you-chose
+        $ gdb /usr/local/lib/ipsec/pluto core
+        (gdb) where
+        (gdb) quit
+        $ exit
+
+The resulting output will have been captured by the script command in
+a file called "typescript".  Send it to the list.
+
+Do not delete the core file.  I may need to ask you to print out some
+more relevant stuff.
Subject: Re: AW: Installing IPsec on Redhat 7.0
+   Date: Thu, 1 Feb 2001 14:32:52 -0200 (BRST)
+  From: Mads Rasmussen <mads@cit.com.br>
+ 
+> From www.redhat.com/support/docs/gotchas/7.0/gotchas-7-6.html#ss6.1
+
+cd to /usr/src/linux and open the Makefile in your favorite editor. You
+will need to look for a line similar to this:
+
+CC = $(CROSS_COMPILE)gcc -D__KERNEL__ -I$(HPATH)
+
+This line specifies which C compiler to use to build the kernel. It should
+be changed to:
+
+CC = $(CROSS_COMPILE)kgcc -D__KERNEL__ -I$(HPATH)
+
+for Red Hat Linux 7. The kgcc compiler is egcs 2.91.66. From here you can
+proceed with the typical compiling steps.
Date: Mon, 30 Nov 1998
+From: Peter Onion <ponion@srd.bt.co.uk>
+
+... I got Saturdays snapshot working between my two SUSE5.3 machines at home.
+
+The mods to the install process are quite simple.  From memory and looking at
+the files on the SUSE53 machine here at work....
+
+And extra link in each of the /etc/init.d/rc?.d directories called K35ipsec
+which SUSE use to shut a service down.
+
+A few mods in /etc/init.d/ipsec  to cope with the different places that SUSE
+put config info, and remove the inculsion of /etc/rc.d/init.d/functions and .
+/etc/sysconfig/network as they don't exists and 1st one isn't needed anyway.
+
+insert ". /etc/rc.config" to pick up the SUSE config info and use 
+
+  if test -n "$NETCONFIG" -a "$NETCONFIG" != "YAST_ASK" ; then
+
+to replace 
+
+  [ ${NETWORKING} = "no" ] && exit 0
+
+Create /etc/sysconfig  as SUSE doesn't have one.
+
+I think that was all (but I prob forgot something)....
Subject: Re: linux-IPsec: Slackware distribution
+  Date:  Thu, 15 Apr 1999 12:07:01 -0700
+  From:  Evan Brewer <dmessiah@silcon.com>
+
+> Very shortly, I will be needing to install IPsec on at least gateways that
+> are running Slackware. . . .
+
+The only trick to getting it up is that on the slackware dist there is no
+init.d directory in /etc/rc.d .. so create one.  Then, what I do is take the
+IPsec startup script which normally gets put into the init.d directory, and
+put it in /etc/rc.d and name ir rc.ipsec .. then I symlink it to the file
+in init.d.  The only file in the dist you need to really edit is the
+utils/Makefile, setup4:
+
+Everything else should be just fine.
Subject: Re: HTML Docs- Need some cleanup?
+   Date: Mon, 8 Jan 2001
+   From: Jody McIntyre <jodym@oeone.com>
+
+I have successfully installed FreeS/WAN on several Slackware 7.1 machines.
+FreeS/WAN installed its rc.ipsec file in /etc/rc.d.  I had to manually call
+this script from rc.inet2.  This seems to be an easier method than Evan
+Brewer's.
Subject: FreeS/WAN 1.0 on Debian 2.1
+   Date: Tue, 20 Apr 1999
+  From:  Tim Miller <cerebus+counterpane@haybaler.sackheads.org>
+
+        Compiled and installed without error on a Debian 2.1 system
+with kernel-source-2.0.36 after pointing RCDIR in utils/Makefile to
+/etc/init.d.
+
+        /var/lock/subsys/ doesn't exist on Debian boxen, needs to be
+created; not a fatal error.
+
+        Finally, IPsec scripts appear to be dependant on GNU awk
+(gawk); the default Debian awk (mawk-1.3.3-2) had fatal difficulties.
+With gawk installed and /etc/alternatives/awk linked to /usr/bin/gawk
+operation appears flawless.
Subject: Re: HTML Docs- Need some cleanup?
+   Date: Mon, 08 Jan 2001
+   From: Andy Bradford <andyb@calderasystems.com>
+
+On Sun, 07 Jan 2001 22:59:05 EST, Sandy Harris wrote:
+
+>     Intel Linux distributions other than Redhat 5.x and 6.x 
+>         Redhat 7.0 
+>         SuSE Linux 
+>             SuSE Linux 5.3 
+>         Slackware 
+>         Debian 
+
+Can you please include Caldera in this list?  I have tested it since 
+FreeS/Wan 1.1 and it works great with our systems---provided one 
+follows the FreeS/Wan documentation. :-)
+
+Thank you,
+Andy
Subject: linux-ipsec: Netwinder diffs
+Date: Wed, 06 Jan 1999
+From: rhatfield@plaintree.com
+
+I had a mistake in my IPsec-auto, so I got things working this morning.
+
+Following are the diffs for my changes.  Probably not the best and cleanest way 
+of doing it, but it works. . . . 
Subject:  Compiling FreeS/WAN 1.1 on YellowDog Linux (PPC)
+   Date:  11 Dec 1999
+   From:  Darron Froese <darron@fudgehead.com>
+
+I'm summarizing here for the record - because it's taken me many hours to do
+this (multiple times) and because I want to see IPsec on more linuxes than
+just x86.
+
+Also, I can't remember if I actually did summarize it before... ;-) I'm
+working too many late hours.
+
+That said - here goes.
+
+1. Get your linux kernel and unpack into /usr/src/linux/ - I used 2.2.13.
+<http://www.kernel.org/pub/linux/kernel/v2.2/linux-2.2.13.tar.bz2>
+
+2. Get FreeS/WAN and unpack into /usr/src/freeswan-1.1
+<ftp://ftp.xs4all.nl/pub/crypto/freeswan/freeswan-1.1.tar.gz>
+
+3. Get the gmp src rpm from here:
+<ftp://ftp.yellowdoglinux.com//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm>
+
+4. Su to root and do this: rpm --rebuild gmp-2.0.2-9a.src.rpm
+
+You will see a lot of text fly by and when you start to see the rpm
+recompiling like this:
+
+Executing: %build
++ umask 022
++ cd /usr/src/redhat/BUILD
++ cd gmp-2.0.2
++ libtoolize --copy --force
+Remember to add `AM_PROG_LIBTOOL' to `configure.in'.
+You should add the contents of `/usr/share/aclocal/libtool.m4' to
+`aclocal.m4'.
++ CFLAGS=-O2 -fsigned-char
++ ./configure --prefix=/usr
+
+Hit Control-C to stop the rebuild. NOTE: We're doing this because for some
+reason the gmp source provided with FreeS/WAN 1.1 won't build properly on
+ydl.
+
+cd /usr/src/redhat/BUILD/
+cp -ar gmp-2.0.2 /usr/src/freeswan-1.1/
+cd /usr/src/freeswan-1.1/
+rm -rf gmp
+mv gmp-2.0.2 gmp
+
+5. Open the freeswan Makefile and change the line that says:
+KERNEL=$(b)zimage (or something like that) to
+KERNEL=vmlinux
+
+6. cd ../linux/
+
+7. make menuconfig
+Select an option or two and then exit - saving your changes.
+
+8. cd ../freeswan-1.1/ ; make menugo
+
+That will start the whole process going - once that's finished compiling,
+you have to install your new kernel and reboot.
+
+That should build FreeS/WAN on ydl (I tried it on 1.1).
Subject: Re: FreeS/WAN, PGPnet and E-mail
+   Date: Sat, 22 Jan 2000
+   From: Darron Froese <darron@fudgehead.com>
+
+on 1/22/00 6:47 PM, Philip Trauring at philip@trauring.com wrote:
+
+> I have a PowerMac G3 ...
+
+The PowerMac G3 can run YDL 1.1 just fine. It should also be able to run
+FreeS/WAN 1.2patch1 with a couple minor modifications:
+
+1. In the Makefile it specifies a bzimage for the kernel compile - you have
+to change that to vmlinux for the PPC.
+
+2. The gmp source that comes with FreeS/WAN (for whatever reason) fails to
+compile. I have gotten around this by getting the gmp src rpm from here:
+
+ftp://ftp.yellowdoglinux.com//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm
+
+If you rip the source out of there - and place it where the gmp source
+resides it will compile just fine.
Subject: Smiles on sparc and ppc
+   Date: Fri, 10 Mar 2000
+   From: Jake Hill <jah@alien.bt.co.uk>
+
+You may or may not be interested to know that I have successfully built
+FreeS/WAN on a number of non intel alpha architectures; namely on ppc
+and sparc and also on osfmach3/ppc (MkLinux). I can report that it just
+works, mostly, with few changes.
Subject: IT WORKS (again) between intel & alpha :-)))))
+   Date: Fri, 29 Jan 1999
+   From: Peter Onion <ponion@srd.bt.co.uk>
+
+Well I'm happy to report that I've got an IPsec connection between by intel & alpha machines again :-))
+
+If you look back on this list to 7th of December I wrote...
+
+-On 07-Dec-98 Peter Onion wrote:
+-> 
+-> I've about had enuf of wandering around inside the kernel trying to find out
+-> just what is corrupting outgoing packets...
+-
+-Its 7:30 in the evening .....
+-
+-I FIXED IT  :-))))))))))))))))))))))))))))))))
+-
+-It was my own fault :-((((((((((((((((((
+-
+-If you ask me very nicly I'll tell you where I was a little too over keen to
+-change unsigned long int __u32 :-)  OPSE ...
+-
+-So tomorrow it will full steam ahead to produce a set of diffs/patches against
+-0.91 
+-
+-Peter Onion.
Subject: Smiles on sparc and ppc
+   Date: Fri, 10 Mar 2000
+   From: Jake Hill <jah@alien.bt.co.uk>
+
+You may or may not be interested to know that I have successfully built
+FreeS/WAN on a number of non intel alpha architectures; namely on ppc
+and sparc and also on osfmach3/ppc (MkLinux). I can report that it just
+works, mostly, with few changes.
+
+I have a question, before I make up some patches. I need to hack
+gmp/mpn/powerpc32/*.s to build them. Is this ok? The changes are
+trivial, but could I also use a different version of gmp? Is it vanilla
+here?
+
+I guess my only real headache is from ipchains, which appears to stop
+running when IPsec has been started for a while. This is with 2.2.14 on
+sparc.
Subject: UltraSPARC DES assembler
+   Date: Thu, 13 Apr 2000
+   From: svolaf@inet.uni2.dk (Svend Olaf Mikkelsen)
+     To: coderpunks@toad.com
+
+An UltraSPARC assembler version of the LibDES/SSLeay/OpenSSL des_enc.c
+file is available at http://inet.uni2.dk/~svolaf/des.htm.
+
+This brings DES on UltraSPARC from slower than Pentium at the same
+clock speed to significantly faster.
Subject: Re: Crypto hardware support
+   Date: Mon, 03 Jul 2000
+   From: Dan DeVault <devault@tampabay.rr.com>
+
+.... I have been running
+uClinux with FreeS/WAN 1.4 on a system built by Moreton Bay  (
+http://www.moretonbay.com )  and it was using a Coldfire processor
+and was able to do the Triple DES encryption at just about
+1 mbit / sec rate.......  they put a Hi/Fn 7901 hardware encryption
+chip on their board and now their system does over 25 mbit of 3DES
+encryption........ pretty significant increase if you ask me.
Subject: [Design] [PATCH] H/W acceleration patch
+   Date: Tue, 18 Sep 2001
+   From: "Martin Gadbois" <martin.gadbois@colubris.com>
+ 
+Finally!!
+Here's a web site with H/W acceleration patch for FreeS/WAN 1.91, including
+S/W and Hifn 7901 crypto support.
+
+http://sources.colubris.com/
+
+Martin Gadbois
 ... Currently shipping chips deliver, 600 mbps throughput on a single
+ stream of 3DES IPsec traffic.  There are also chips that use multiple
+ cores to do 2.4 gbps.  We (Cavium) and others have announced even faster
+ chips. ... Mid 2002 versions will handle at line rate (OC48 and OC192)
+ IPsec and SSL/TLS traffic not only 3DES CBC but also AES and arc4.
Subject: Re: Maximum number of ipsec tunnels?
+   Date: Tue, 18 Apr 2000
+   From: "John S. Denker" <jsd@research.att.com>
+
+Christopher Ferris wrote:
+
+>> What are the maximum number ipsec tunnels FreeS/WAN can handle??
+
+Henry Spencer wrote:
+
+>There is no particular limit.  Some of the setup procedures currently
+>scale poorly to large numbers of connections, but there are (clumsy)
+>workarounds for that now, and proper fixes are coming.
+
+1) "Large" numbers means anything over 50 or so.  I routinely run boxes
+with about 200 tunnels.  Once you get more than 50 or so, you need to worry
+about several scalability issues:
+
+a) You need to put a "-" sign in syslogd.conf, and rotate the logs daily
+not weekly.
+
+b) Processor load per tunnel is small unless the tunnel is not up, in which
+case a new half-key gets generated every 90 seconds, which can add up if
+you've got a lot of down tunnels.
+
+c) There's other bits of lore you need when running a large number of
+tunnels.  For instance, systematically keeping the .conf file free of
+conflicts requires tools that aren't shipped with the standard freeswan
+package.
+
+d) The pluto startup behavior is quadratic.  With 200 tunnels, this eats up
+several minutes at every restart.   I'm told fixes are coming soon.
+
+2) Other than item (1b), the CPU load depends mainly on the size of the
+pipe attached, not on the number of tunnels.
+
Subject: Re: linux-ipsec: IPSec Masquerade
+   Date: Fri, 15 Jan 1999 11:13:22 -0500
+   From: Michael Richardson 
+
+. . . A 486/66 has been clocked by Phil Karn to do
+10Mb/s encryption.. that uses all the CPU, so half that to get some CPU,
+and you have 5Mb/s. 1/3 that for 3DES and you get 1.6Mb/s....
Oh yes, and a new timing point for Sandy's docs...  A P60 -- yes, a 60MHz
+Pentium, talk about antiques -- running a host-to-host tunnel to another
+machine shows an FTP throughput (that is, end-to-end results with a real
+protocol) of slightly over 5Mbit/s either way.  (The other machine is much
+faster, the network is 100Mbps, and the ether cards are good ones... so
+the P60 is pretty definitely the bottleneck.)
Subject: FreeSWAN (specically KLIPS) performance measurements
+   Date: Thu, 01 Feb 2001
+   From: Nigel Metheringham <Nigel.Metheringham@intechnology.co.uk>
+
+I've spent a happy morning attempting performance tests against KLIPS 
+(this is due to me not being able to work out the CPU usage of KLIPS so 
+resorting to the crude measurements of maximum throughput to give a 
+baseline to work out loading of a box).
+
+Measurements were done using a set of 4 boxes arranged in a line, each 
+connected to the next by 100Mbit duplex ethernet.  The inner 2 had an 
+ipsec tunnel between them (shared secret, but I was doing measurements 
+when the tunnel was up and running - keying should not be an issue 
+here).  The outer pair of boxes were traffic generators or traffic sink.
+
+The crypt boxes are Compaq DL380s - Uniprocessor PIII/733 with 256K 
+cache.  They have 128M main memory.  Nothing significant was running on 
+the boxes other than freeswan.  The kernel was a 2.2.19pre7 patched 
+with freeswan and ext3.
+
+Without an ipsec tunnel in the chain (ie the 2 inner boxes just being 
+100BaseT routers), throughput (measured with ttcp) was between 10644 
+and 11320 KB/sec
+
+With an ipsec tunnel in place, throughput was between 3268 and 3402 
+KB/sec
+
+These measurements are for data pushed across a TCP link, so the 
+traffic on the wire between the 2 ipsec boxes would have been higher 
+than this....
+
+vmstat (run during some other tests, so not affecting those figures) on 
+the encrypting box shows approx 50% system & 50% idle CPU - which I 
+don't believe at all.  Interactive feel of the box was significantly 
+sluggish.
+
+I also tried running the kernel profiler (see man readprofile) during 
+test runs.
+
+A box doing primarily decrypt work showed basically nothing happening - 
+I assume interrupts were off.
+A box doing encrypt work showed the following:-
+ Ticks Function                                   Load
+ ~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    ~~~~~~
+   956 total                                      0.0010
+   532 des_encrypt2                               0.1330
+   110 MD5Transform                               0.0443
+    97 kmalloc                                    0.1880
+    39 des_encrypt3                               0.1336
+    23 speedo_interrupt                           0.0298
+    14 skb_copy_expand                            0.0250
+    13 ipsec_tunnel_start_xmit                    0.0009
+    13 Decode                                     0.1625
+    11 handle_IRQ_event                           0.1019
+    11 .des_ncbc_encrypt_end                      0.0229
+    10 speedo_start_xmit                          0.0188
+     9 satoa                                      0.0225
+     8 kfree                                      0.0118
+     8 ip_fragment                                0.0121
+     7 ultoa                                      0.0365
+     5 speedo_rx                                  0.0071
+     5 .des_encrypt2_end                          5.0000
+     4 _stext                                     0.0140
+     4 ip_fw_check                                0.0035
+     2 rj_match                                   0.0034
+     2 ipfw_output_check                          0.0200
+     2 inet_addr_type                             0.0156
+     2 eth_copy_and_sum                           0.0139
+     2 dev_get                                    0.0294
+     2 addrtoa                                    0.0143
+     1 speedo_tx_buffer_gc                        0.0024
+     1 speedo_refill_rx_buf                       0.0022
+     1 restore_all                                0.0667
+     1 number                                     0.0020
+     1 net_bh                                     0.0021
+     1 neigh_connected_output                     0.0076
+     1 MD5Final                                   0.0083
+     1 kmem_cache_free                            0.0016
+     1 kmem_cache_alloc                           0.0022
+     1 __kfree_skb                                0.0060
+     1 ipsec_rcv                                  0.0001
+     1 ip_rcv                                     0.0014
+     1 ip_options_fragment                        0.0071
+     1 ip_local_deliver                           0.0023
+     1 ipfw_forward_check                         0.0139
+     1 ip_forward                                 0.0011
+     1 eth_header                                 0.0040
+     1 .des_encrypt3_end                          0.0833
+     1 des_decrypt3                               0.0034
+     1 csum_partial_copy_generic                  0.0045
+     1 call_out_firewall                          0.0125
+
+Hope this data is helpful to someone... however the lack of visibility 
+into the decrypt side makes things less clear
Subject: [Users] Speed with compression
+   Date: Fri, 29 Jun 2001
+   From: John McMonagle <johnm@advocap.org>
+
+Did a couple tests with compression using the new 1.91 freeswan.
+
+Running between 2 sites with cable modems.  Both  using approximately
+130 mhz pentium.
+
+Transferred files with ncftp.
+
+Compressed file was a 6mb compressed  installation file.
+Non compressed was 18mb /var/lib/rpm/packages.rpm
+
+                            Compressed vpn          regular vpn
+Compress file                42.59 kBs               42.08 kBs
+regular file                110.84 kBs               41.66 kBs
+
+Load  was about 0 either way.
+Ping times were very similar  a bit above 9 ms.
+
+Compression looks attractive to me.
> is there a reason not to switch compression on?  I have large gateway boxes
+> connecting 3 connections, one of them with a measly DS1 link...
+
+Run some timing tests with and without, with data and loads representative
+of what you expect in production.  That's the definitive way to decide. 
+If compression is a net loss, then obviously, leave it turned off.  If it
+doesn't make much difference, leave it off for simplicity and hence
+robustness.  If there's a substantial gain, by all means turn it on. 
+
+If both ends support compression and can successfully negotiate a
+compressed connection (trivially true if both are FreeS/WAN 1.91), then
+the crucial question is CPU cycles. 
+
+Compression has some overhead, so one question is whether *your* data
+compresses well enough to save you more CPU cycles (by reducing the volume
+of data going through CPU-intensive encryption/decryption) than it costs
+you.  Last time I ran such tests on data that was reasonably compressible
+but not deliberately contrived to be so, this generally was not true --
+compression cost extra CPU cycles -- so compression was worthwhile only if
+the link, not the CPU, was the bottleneck.  However, that was before the
+slow-compression bug was fixed.  I haven't had a chance to re-run those
+tests yet, but it sounds like I'd probably see a different result. 
> I have a batch of boxes doing Freeswan stuff.
+> I want to measure the CPU loading of the Freeswan tunnels, but am 
+> having trouble seeing how I get some figures out...
+> 
+>  - Keying etc is in userspace so will show up on the per-process
+>    and load average etc (ie pluto's load)
+
+Correct.
+
+>  - KLIPS is in the kernel space, and does not show up in load average
+>    I think also that the KLIPS per-packet processing stuff is running
+>    as part of an interrupt handler so it does not show up in the
+>    /proc/stat system_cpu or even idle_cpu figures
+
+It is not running in interrupt handler.  It is in the bottom half.
+This is somewhere between user context (careful, this is not
+userspace!) and hardware interrupt context.
+
+> Is this correct, and is there any means of instrumenting how much the 
+> cpu is being loaded - I don't like the idea of a system running out of 
+> steam whilst still showing 100% idle CPU :-)
+
+vmstat seems to do a fairly good job, but use a running tally to get a
+good idea.  A one-off call to vmstat gives different numbers than a
+running stat.  To do this, put an interval on your vmstat command
+line.
Subject: Re: Measuring the CPU usage of Freeswan
+   Date: Mon, 29 Jan 2001
+   From: Patrick Michael Kane <modus@pr.es.to>
+ 
+The only truly accurate way to accurately track FreeSWAN CPU usage is to use
+a CPU soaker. You run it on an unloaded system as a benchmark, then start up
+FreeSWAN and take the difference to determine how much FreeSWAN is eating.
+I believe someone has done this in the past, so you may find something in
+the FreeSWAN archives.  If not, someone recently posted a URL to a CPU
+soaker benchmark tool on linux-kernel.
    ipsec setup status
    service ipsec restart
   links oetest.freeswan.org
   links oetest.freeswan.nl
+   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
+
   links oetest.freeswan.org
   links oetest.freeswan.nl
+   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
+
   ipsec eroute
    192.0.2.11/32   -> 192.139.46.73/32  => tun0x149f@192.139.46.38
+
    02:17:47.353750 PPPoE  [ses 0x1e12] IP 154: xy.example.com > oetest.freeswan.org: ESP(spi=0x87150d16,seq=0x55)
      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
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:
conn abc-xyz
+      left=192.168.p.1
+      leftnexthop=192.168.p.2
+      right=192.168.q.1
+      rightnexthop=192.168.q.2
> 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).
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....)
        ping -p feedfacedeadbeef 11.0.1.1
        echo 1 > /proc/sys/net/ipv4/ipforward
+   append="ether=0,0,eth0 ether=0,0,eth1"
+
        netA---gwA---gwB---netB
+                            |----netC
+
+   netA and B are secured netC not.
+   netA and gwA can not access netC
  The simplest way and indeed the right way to
+  solve this problem is to set up two connections:
+
+        leftsubnet=NetA
+        left=gwA
+        right=gwB
+        rightsubnet=NetB
+  and
+        leftsubnet=NetA
+        left=gwA
+        right=gwB
+        rightsubnet=NetC
     Sunset==========West------------------East=========Sunrise
+           local net       untrusted net       local net
                                           telecommuter's PC or
+                                           traveller's laptop
+     Sunset==========West------------------East
+         corporate LAN     untrusted net
     Sunset==========West------------------East ================= firewall --- the Internet
+         home network      untrusted net        corporate network
          West-----------------------------East == the rest of your network
+     workstation   untrusted wireless net
        ipsec manual --up name
+        ipsec auto --up name
        10.0.0.1 11.0.0.1 : PSK "jxTR1lnmSjuj33n4W51uW3kTR55luUmSmnlRUuWnkjRj3UuTV4T3USSu23Uk55nWu5TkTUnjT"
        10.0.0.1 0.0.0.0 : PSK "jxTR1lnmSjuj33n4W51uW3kTR55luUmSmnlRUuWnkjRj3UuTV4T3USSu23Uk55nWu5TkTUnjT"
        also=samplesep-keys
include ipsec.*.conf
conn samplesep-keys
+  spi=0x200
+  esp=3des-md5-96
+  espenckey=0x01234567_89abcdef_02468ace_13579bdf_12345678_9abcdef0
+  espauthkey=0x12345678_9abcdef0_2468ace0_13579bdf
      umask 177
+      ipsec ranbits 192  > temp
+      ipsec ranbits 128 >> temp
         192.168.100.0/24           left subnet
+              |
+         192.168.100.1
+         North Gateway
+         101.101.101.101            left
+              |
+         101.101.101.1              left next hop
+         [Internet]
+         202.202.202.1              right next hop
+              |
+         202.202.202.202            right
+         South gateway
+         192.168.200.1
+              |
+         192.168.200.0/24           right subnet
conn northnet-southnet
+      left=101.101.101.101
+      leftnexthop=101.101.101.1
+      leftsubnet=192.168.100.0/24
+      leftfirewall=yes
+      right=202.202.202.202
+      rightnexthop=202.202.202.1
+      rightsubnet=192.168.200.0/24
+      rightfirewall=yes
conn northgate-southnet
+      left=101.101.101.101
+      leftnexthop=101.101.101.1
+      right=202.202.202.202
+      rightnexthop=202.202.202.1
+      rightsubnet=192.168.200.0/24
+      rightfirewall=yes
+
+conn northnet-southgate
+      left=101.101.101.101
+      leftnexthop=101.101.101.1
+      leftsubnet=192.168.100.0/24
+      leftfirewall=yes
+      right=202.202.202.202
+      rightnexthop=202.202.202.1
conn northgate-southgate
+      left=101.101.101.101
+      leftnexthop=101.101.101.1
+      right=202.202.202.202
+      rightnexthop=202.202.202.1
Subject: Re: linux-ipsec: IPSec packets not entering tunnel?
+   Date: Mon, 20 Nov 2000
+   From: Justin Guyett <jfg@sonicity.com>
+
+On Mon, 20 Nov 2000, Claudia Schmeing wrote:
+
+> Right                                                         Left
+>                      "home"                "office"
+> 10.92.10.0/24 ---- 24.93.85.110 ========= 216.175.164.91 ---- 10.91.10.24/24
+>
+> I've created all four tunnels, and can ping to test each of them,
+> *except* homegate-officenet.
+
+I keep wondering why people create all four tunnels.  Why not route
+traffic generated from home to 10.91.10.24/24 out ipsec0 with iproute2?
+And 99% of the time you don't need to access "office" directly, which
+means you can eliminate all but the subnet<->subnet connection.
> I keep wondering why people create all four tunnels.  Why not route
+> traffic generated from home to 10.91.10.24/24 out ipsec0 with iproute2?
+
+This is feasible, given some iproute2 attention to source addresses, but
+it isn't something we've documented yet... (partly because we're still
+making some attempt to support 2.0.xx kernels, which can't do this, but
+mostly because we haven't caught up with it yet).
+
+> And 99% of the time you don't need to access "office" directly, which
+> means you can eliminate all but the subnet<->subnet connection.
+
+Correct in principle, but people will keep trying to ping to or from the
+gateways during testing, and sometimes they want to run services on the
+gateway machines too.
    ipsec showhostkey --txt 192.0.2.11
    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
+    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
+    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
+                                                                                
+    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
+    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
+                                                                                
+    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
+    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
    98.2.0.192.in-addr.arpa. IN PTR arthur.example.com.
    98.2.0.192.in-addr.arpa. IN PTR arthur.example.com.
+    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
+    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
+                                                                                
+    99.2.0.192.in-addr.arpa. IN PTR ford.example.com.
+    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
+    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
+                                                                                
+    100.2.0.192.in-addr.arpa. IN PTR trillian.example.com.
+    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
+    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
    ipsec verify --host ford.example.com
+    ipsec verify --host trillian.example.com
    ...
+    Looking for TXT in reverse map: 99.2.0.192.in-addr.arpa [OK]
+    ...
+    Looking for TXT in reverse map: 11.2.0.192.in-addr.arpa   [OK]
+    ...
+    Looking for TXT in reverse map: 100.2.0.192.in-addr.arpa [OK]
+    ...
+    Looking for TXT in reverse map: 11.2.0.192.in-addr.arpa   [OK]
+    ...
    subnet           gateway          Internet
+  a.b.c.0/24    a.b.c.1    p.q.r.s
    subnet           gateway          Internet       your gate  extruded
+
+  a.b.c.0/24   a.b.c.1     p.q.r.s              d.e.f.g         a.b.c.240/28                
+
+                           ========== tunnel ==========
conn extruded
+        left=p.q.r.s
+        leftsubnet=0.0.0.0/0
+        right=d.e.f.g
+        rightsubnet=a.b.c.0/28
Subject: Re: linux-ipsec: understanding the vpn
+   Date: Thu, 28 Oct 1999 10:43:22 -0400
+   From: Irving Reid <irving@nevex.com>
+
+>  local-------linux------internet------mobile
+>  LAN        box                         user
+>  ...
+
+>  now when the mobile user connects to the linux box
+>  it is given a virtual IP address, i have configured it to
+>  be in the 10.x.x.x range. mobile user and linux box 
+>  have a tunnel between them with these IP addresses.
+
+>   Uptil this all is fine.
+
+If it is possible to configure your mobile client software *not* to
+use a virtual IP address, that will make your life easier. It is easier
+to configure FreeS/WAN to use the actual address the mobile user gets
+from its ISP.
+
+Unfortunately, some Windows clients don't let you choose.
+
+>  what i would like to know is that how does the mobile
+>  user communicate with other computers on the local
+>  LAN , of course with the vpn ?
+
+>   what IP address should the local LAN 
+>  computers have ? I guess their default gateway 
+>  should be the linux box ? and does the linux box need
+>  to be a 2 NIC card box or one is fine.
+
+As someone else stated, yes, the Linux box would usually be the default
+IP gateway for the local lan.
+
+However...
+
+If you mobile user has software that *must* use a virtual IP address,
+the whole picture changes. Nobody has put much effort into getting
+FreeS/WAN to play well in this environment, but here's a sketch of one
+approach:
+
+Local Lan 1.0.0.0/24
+    |
+    +- Linux FreeS/WAN 1.0.0.2
+    |
+    | 1.0.0.1
+ Router
+    | 2.0.0.1
+    |
+Internet
+    |
+    | 3.0.0.1
+Mobile User
+      Virtual Address: 1.0.0.3
+
+Note that the Local Lan network (1.0.0.x) can be registered, routable
+addresses.
+
+Now, the Mobile User sets up an IPSec security association with the
+Linux box (1.0.0.2); it should ESP encapsulate all traffic to the
+network 1.0.0.x **EXCEPT** UDP port 500. 500/udp is required for the key
+negotiation, which needs to work outside of the IPSec tunnel.
+
+On the Linux side, there's a bunch of stuff you need to do by hand (for
+now). FreeS/WAN should correctly handle setting up the IPSec SA and
+routes, but I haven't tested it so this may not work...
+
+The FreeS/WAN conn should look like:
+
+conn mobile
+        right=1.0.0.2
+        rightsubnet=1.0.0.0/24
+        rightnexthop=1.0.0.1
+        left=0.0.0.0  # The infamous "road warrior"
+        leftsubnet=1.0.0.3/32
+
+Note that the left subnet contains *only* the remote host's virtual
+address.
+
+Hopefully the routing table on the FreeS/WAN box ends up looking like
+this:
+
+% netstat -rn
+Kernel IP routing table
+Destination     Gateway      Genmask         Flags   MSS Window  irtt Iface
+1.0.0.0         0.0.0.0      255.255.255.0   U      1500 0          0 eth0
+127.0.0.0       0.0.0.0      255.0.0.0       U      3584 0          0 lo
+0.0.0.0         1.0.0.1      0.0.0.0         UG     1500 0          0 eth0
+1.0.0.3         1.0.0.1      255.255.255.255 UG     1433 0          0 ipsec0
+
+So, if anybody sends a packet for 1.0.0.3 to the Linux box, it should
+get bundled up and sent through the tunnel. To get the packets for
+1.0.0.3 to the Linux box in the first place, you need to use "proxy
+ARP".
+
+How this works is: when a host or router on the local Ethernet segment
+wants to send a packet to 1.0.0.3, it sends out an Ethernet level
+broadcast "ARP request". If 1.0.0.3 was on the local LAN, it would
+reply, saying "send IP packets for 1.0.0.3 to my Ethernet address".
+
+Instead, you need to set up the Linux box so that _it_ answers ARP
+requests for 1.0.0.3, even though that isn't its IP address. That
+convinces everyone else on the lan to send 1.0.0.3 packets to the Linux
+box, where the usual FreeS/WAN processing and routing take over.
+
+% arp -i eth0 -s 1.0.0.3 -D eth0 pub
+
+This says, if you see an ARP request on interface eth0 asking for
+1.0.0.3, respond with the Ethernet address of interface eth0.
+
+Now, as I said at the very beginning, if it is *at all* possible to
+configure your client *not* to use the virtual IP address, you can avoid
+this whole mess.
        chkconfig --level 2345 ipsec off
        interfaces=
        ipsec setup start
        ipsec setup restart
        ipsec setup restart
    ipsec newhostkey --output /etc/ipsec.secrets --hostname xy.example.com
+    chmod 600 /etc/ipsec.secrets
: RSA   {
+        # RSA 2192 bits   xy.example.com   Sun Jun 8 13:42:19 2003
+        # for signatures only, UNSAFE FOR ENCRYPTION
+        #pubkey=0sAQOFppfeE3cC7wqJi...
+        Modulus: 0x85a697de137702ef0...
+        # everything after this point is secret
+        PrivateExponent: 0x16466ea5033e807...
+        Prime1: 0xdfb5003c8947b7cc88759065...
+        Prime2: 0x98f199b9149fde11ec956c814...
+        Exponent1: 0x9523557db0da7a885af90aee...
+        Exponent2: 0x65f6667b63153eb69db8f300dbb...
+        Coefficient: 0x90ad00415d3ca17bebff123413fc518...
+        }
+# do not change the indenting of that "}"
    freeswan-userland-2.04.9-0.i386.rpm
    uname -r
    freeswan-module-2.04_2.4.20_20.9-0.i386.rpm
    freeswan-userland-2.04_2.4.20_20.9-0.i386.rpm
    freeswan-rpmsign.asc
    rpm --import freeswan-rpmsign.asc
    pgp -ka freeswan-rpmsign.asc
    rpm --checksig freeswan*.rpm 
    freeswan-module-2.04_2.4.20_20.9-0.i386.rpm: pgp md5 OK
+    freeswan-userland-2.04_2.4.20_20.9-0.i386.rpm: pgp md5 OK
    su
    rpm -ivh freeswan*.rpm
    rpm -Uvh freeswan*.rpm
    freeswan-sigkey.asc
    pgp -ka freeswan-sigkey.asc
    pgp freeswan-2.04.tar.gz.sig freeswan-2.04.tar.gz
    Good signature from user "Linux FreeS/WAN Software Team (build@freeswan.org)".
+    Signature made 2002/06/26 21:04 GMT using 2047-bit key, key ID 46EAFCE1
    su
+    mv freeswan-2.04.tar.gz /usr/src
+    cd /usr/src
+    tar -xzf freeswan-2.04.tar.gz
+
    cd /usr/src/freeswan-2.04
+    make programs
+    make install
    cd /usr/src/freeswan-2.04
+    make oldmod
+    make minstall
    cd /usr/src/freeswan-2.04
+    make oldmod
+    make minstall
    service ipsec start
    ipsec verify
+    Checking your system to see if IPsec got installed and started correctly
+    Version check and ipsec on-path                             [OK]
+    Checking for KLIPS support in kernel                        [OK]
+    Checking for RSA private key (/etc/ipsec.secrets)           [OK]
+    Checking that pluto is running                              [OK]
+
    ipsec showhostkey --left
    # RSA 2048 bits   xy.example.com   Fri Apr 26 15:01:41 2002
+    leftrsasigkey=0sAQOnwiBPt...
    ssh2 ab.example.com
    ipsec showhostkey --right
    # RSA 2192 bits   ab.example.com   Thu May 16 15:26:20 2002
+    rightrsasigkey=0sAQOqH55O...
conn net-to-net
+    left=192.0.2.2                 # Local vitals
+    leftsubnet=192.0.2.128/29      # 
+    leftid=@xy.example.com         #   
+    leftrsasigkey=0s1LgR7/oUM...   #
+    leftnexthop=%defaultroute      # correct in many situations 
+    right=192.0.2.9                # Remote vitals
+    rightsubnet=10.0.0.0/24        #
+    rightid=@ab.example.com        # 
+    rightrsasigkey=0sAQOqH55O...   #
+    rightnexthop=%defaultroute     # correct in many situations
+    auto=add                       # authorizes but doesn't start this 
+                                   # connection at startup
    scp2 ipsec.conf root@ab.example.com:/etc/ipsec.conf
    ipsec auto --up net-to-net
    104 "net-net" #223: STATE_MAIN_I1: initiate
+    106 "net-net" #223: STATE_MAIN_I2: sent MI2, expecting MR2
+    108 "net-net" #223: STATE_MAIN_I3: sent MI3, expecting MR3
+    004 "net-net" #223: STATE_MAIN_I4: ISAKMP SA established
+    112 "net-net" #224: STATE_QUICK_I1: initiate
+    004 "net-net" #224: STATE_QUICK_I2: sent QI2, IPsec SA established
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE
+
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 192.0.2.128/29 -j MASQUERADE
    ping fileserver.toledo.example.com
    tcpdump -i ppp0
    19:16:32.046220 192.0.2.2 > 192.0.2.9: ESP(spi=0x3be6c4dc,seq=0x3)
+    19:16:32.085630 192.0.2.9 > 192.0.2.2: ESP(spi=0x5fdd1cf8,seq=0x6)
conn winstonnet-toledonet
    auto=add
    auto=start
    scp2 ipsec.conf root@ab.example.com:/etc/ipsec.conf
    ipsec showhostkey --left
    # RSA 2192 bits   road.example.com   Sun Jun  9 02:45:02 2002
+    leftrsasigkey=0sAQPIPN9uI...
    ssh2 xy.example.com
    ipsec showhostkey --right
    # RSA 2048 bits   xy.example.com   Fri Apr 26 15:01:41 2002
+    rightrsasigkey=0sAQOnwiBPt...
conn road
+    left=%defaultroute             # Picks up our dynamic IP 
+    leftnexthop=%defaultroute      # 
+    leftid=@road.example.com       # Local information
+    leftrsasigkey=0sAQPIPN9uI...   #
+    right=192.0.2.10               # Remote information
+    rightsubnet=10.0.0.0/24        #
+    rightid=@xy.example.com        # 
+    rightrsasigkey=0sAQOnwiBPt...  #
+    auto=add                       # authorizes but doesn't start this
+                                   # connection at startup
    ssh2 xy.example.com
+    vi /etc/ipsec.conf
conn road
+    left=192.0.2.2                 # Gateway's information
+    leftid=@xy.example.com         #
+    leftsubnet=192.0.2.128/29      #
+    leftrsasigkey=0sAQOnwiBPt...   #
+    rightnexthop=%defaultroute     # correct in many situations
+    right=%any                     # Wildcard: we don't know the laptop's IP
+    rightid=@road.example.com      #
+    rightrsasigkey=0sAQPIPN9uI...  #
+    auto=add                       # authorizes but doesn't start this
+                                   # connection at startup
    ipsec auto --start net-to-net
104 "net-net" #223: STATE_MAIN_I1: initiate
+106 "road" #301: STATE_MAIN_I2: sent MI2, expecting MR2
+108 "road" #301: STATE_MAIN_I3: sent MI3, expecting MR3
+004 "road" #301: STATE_MAIN_I4: ISAKMP SA established
+112 "road" #302: STATE_QUICK_I1: initiate
+004 "road" #302: STATE_QUICK_I2: sent QI2, IPsec SA established
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE
+
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 192.0.2.128/29 -j MASQUERADE
    ping ns.winston.example.com
    tcpdump -i wlan0
    19:16:32.046220 192.0.2.2 > 192.0.2.9: ESP(spi=0x3be6c4dc,seq=0x3)
+    19:16:32.085630 192.0.2.9 > 192.0.2.2: ESP(spi=0x5fdd1cf8,seq=0x6)
conn mike-to-office
    auto=add
    auto=start
        gateway.example.com. IN A 10.20.30.40
+        40.30.20.10.in-addr.arpa. IN PTR gateway.example.com.
The problem is IP fragmentation; more precisely, the problem is that the
+second, third, etc. fragments of an IP packet are often difficult for
+filtering mechanisms to classify.
+
+Routers cannot rely on reassembling the packet, or remembering what was in
+earlier fragments, because the fragments may be out of order or may even
+follow different routes.  So any general, worst-case filtering decision
+pretty much has to be made on each fragment independently.  (If the router
+knows that it is the only route to the destination, so all fragments
+*must* pass through it, reassembly would be possible... but most routers
+don't want to bother with the complications of that.)
+
+All fragments carry roughly the original IP header, but any higher-level
+header is (for IP purposes) just the first part of the packet data... so
+only the first fragment carries that.  So, for example, on examining the
+second fragment of a TCP packet, you could tell that it's TCP, but not
+what port number it is destined for -- that information is in the TCP
+header, which appears in the first fragment only. 
+
+The result of this classification difficulty is that stupid routers and
+over-paranoid firewalls may just throw fragments away.  To get through
+them, you must reduce your MTU enough that fragmentation will not occur.
+(In some cases, they might be willing to attempt reassembly, but have very
+limited resources to devote to it, meaning that packets must be small and
+fragments few in number, leading to the same conclusion:  smaller MTU.)
Here are a couple of pieces of background information. Apologies if you
+have seen these already. An excerpt from one of my old posts:
+
+    An MTU of 16260 on ipsec0 is usual. The IPSec device defaults to this 
+    high MTU so that it does not fragment incoming packets before encryption 
+    and encapsulation. If after IPSec processing packets are larger than 1500,
+    [ie. the mtu of eth0] then eth0 will fragment them. 
+
+    Adding IPSec headers adds a certain number of bytes to each packet. 
+    The MTU of the IPSec interface refers to the maximum size of the packet
+    before the IPSec headers are added. In some cases, people find it helpful 
+    to set ipsec0's MTU to 1500-(IPSec header size), which IIRC is about 1430.
+
+    That way, the resulting encapsulated packets don't exceed 1500. On most 
+    networks, packets less than 1500 will not need to be fragmented.
+
+and... (from Henry Spencer)
+
+    The way it *ought* to work is that the MTU advertised by the ipsecN
+    interface should be that of the underlying hardware interface, less a
+    pinch for the extra headers needed. 
+
+    Unfortunately, in certain situations this breaks many applications.
+    There is a widespread implicit assumption that the smallest MTUs are 
+    at the ends of paths, not in the middle, and another that MTUs are 
+    never less than 1500.  A lot of code is unprepared to handle paths 
+    where there is an "interior minimum" in the MTU, especially when it's 
+    less than 1500. So we advertise a big MTU and just let the resulting 
+    big packets fragment.
+
+This usually works, but we do get bitten in cases where some intermediate
+point can't handle all that fragmentation.  We can't win on this one.
+From: Poltorak Serguei <poltorak@dataforce.net>
+Subject: [Users] Using FreeS/WAN
+Date: Tue, 16 Oct 2001
+
+Hello.
+
+I'm using FreeS/WAN IPsec for half a year. I learned a lot of things about
+it and I think it would be interesting for someone to see the result of my
+experiments and usage of FreeS/WAN. If you find a mistake in this
+file, please e-mail me. And excuse me for my english... I'm learning.. :)
+
+I'll talk about vary simple configuration:
+
+addresses prefix = 192.168
+
+    lan1          sgw1     .0.0/24 (Internet)       sgw2            lan2
+  .1.0/24---[ .1.1 ; .0.1 ]===================[ .0.10 ; . 2.10 ]---.2.0/24
+
+
+We need to let lan1 see lan2 across Internet like it is behind sgw1. The
+same for lan2. And we need to do IPX bridge for Novel Clients and NDS
+synchronization.
+
+my config:
+------------------- ipsec.conf -------------------
+conn lan1-lan2
+        type=tunnel
+        compress=yes
+        #-------------------
+        left=192.168.0.1
+        leftsubnet=192.168.1.0/24
+        #-------------------
+        right=192.168.0.10
+        rightsubnet=192.168.2.0/24
+        #-------------------
+        auth=esp
+        authby=secret
+--------------- end of ipsec.conf ----------------
+
+ping .2.x from .1.y   (y != 1)
+It works?? Fine. Let's continue...
+
+Why y != 1 ?? Because kernel of sgw1 have 2 IP addresses and it will choose
+the first IP (which is used to go to Internet) .0.1 and the packet won't go
+through IPsec tunnel :(  But if do ping on .1.1 kernel will respond from
+that address (.1.1) and the packet will be tunneled. The same problem occurred then
+.2.x sends a packet to .1.2 which is down at the moment. What happens? .1.1
+sends ARP requesting .1.2... after 3 tries it send to .2.x an destunreach,
+but from his "natural" IP or .0.1 . So the error message won't be delivered!
+It's a big problem...
+
+Resolution... One can manipulate with ipsec0 or ipsec0:0 to solve the
+problem (if ipsec0 has .1.1 kernel will send packets correctly), but there
+are powerful and elegant iproute2 :) We simply need to change source address
+of packet that goes to other secure lan. This is done with
+
+ip route replace 192.168.2.0/24 via 192.168.0.10 dev ipsec0 src 192.168.1.1
+
+Cool!! Now it works!!
+
+The second step. We want install firewall on sgw1 and sgw2. Encryption of 
+traffic without security isn't a good idea. I don't use {left|right}firewall, 
+because I'm running firewall from init scripts.
+
+We want IPsec data between lan1-lan2, some ICMP errors (destination
+unreachable, TTL exceeded, parameter problem and source quench), replying on 
+pings from both lans and Internet, ipxtunnel data for IPX and of course SSH
+between sgw1 and sgw2 and from/to one specified host.
+
+I'm using ipchains. With iptables there are some changes.
+
+---------------- rc.firewall ---------------------
+#!/bin/sh
+#
+# Firewall for IPsec lan1-lan2
+#
+
+IPC=/sbin/ipchains
+ANY=0.0.0.0/0
+
+# left
+SGW1_EXT=192.168.0.1
+SGW1_INT=192.168.1.1
+LAN1=192.168.1.0/24
+
+# right
+SGW2_EXT=192.168.0.10
+SGW2_INT=192.168.2.10
+LAN2=192.168.2.0/24
+
+# SSH from and to this host
+SSH_PEER_HOST=_SOME_HOST_
+
+# this is for left. exchange these values for right.
+MY_EXT=$SGW1_EXT
+MY_INT=$SGW1_INT
+PEER_EXT=$SGW2_EXT
+PEER_INT=$SGW2_INT
+INT_IF=eth1
+EXT_IF=eth0
+IPSEC_IF=ipsec0
+MY_LAN=$LAN1
+PEER_LAN=$LAN2
+
+$IPC -F
+$IPC -P input DENY
+$IPC -P forward DENY
+$IPC -P output DENY
+
+# Loopback traffic
+$IPC -A input -i lo -j ACCEPT
+$IPC -A output -i lo -j ACCEPT
+
+# for IPsec SGW1-SGW2
+## IKE
+$IPC -A input -p udp -s $PEER_EXT 500 -d $MY_EXT 500 -i $EXT_IF -j ACCEPT
+$IPC -A output -p udp -s $MY_EXT 500 -d $PEER_EXT 500 -i $EXT_IF -j ACCEPT
+## ESP
+$IPC -A input -p 50 -s $PEER_EXT -d $MY_EXT -i $EXT_IF -j ACCEPT
+### we don't need this line ### $IPC -A output -p 50 -s $MY_EXT -d $PEER_EXT -i $EXT_IF -j ACCEPT
+## forward LAN1-LAN2
+$IPC -A forward -s $MY_LAN -d $PEER_LAN -i $IPSEC_IF -j ACCEPT
+$IPC -A forward -s $PEER_LAN -d $MY_LAN -i $INT_IF -j ACCEPT
+$IPC -A output -s $PEER_LAN -d $MY_LAN -i $INT_IF -j ACCEPT
+$IPC -A input -s $PEER_LAN -d $MY_LAN -i $IPSEC_IF -j ACCEPT
+$IPC -A input -s $MY_LAN -d $PEER_LAN -i $INT_IF -j ACCEPT
+$IPC -A output -s $MY_LAN -d $PEER_LAN -i $IPSEC_IF -j ACCEPT
+
+# ICMP
+#
+## Dest unreachable
+### from/to Internet
+$IPC -A input -p icmp --icmp-type destination-unreachable -s $ANY -d $MY_EXT -i $EXT_IF -j ACCEPT
+$IPC -A output -p icmp --icmp-type destination-unreachable -s $MY_EXT -d $ANY -i $EXT_IF -j ACCEPT
+### from/to Lan
+$IPC -A input -p icmp --icmp-type destination-unreachable -s $ANY -d $MY_INT -i $INT_IF -j ACCEPT
+$IPC -A output -p icmp --icmp-type destination-unreachable -s $MY_INT -d $ANY -i $INT_IF -j ACCEPT
+### from/to Peer Lan
+$IPC -A input -p icmp --icmp-type destination-unreachable -s $ANY -d $MY_INT -i $IPSEC_IF -j ACCEPT
+$IPC -A output -p icmp --icmp-type destination-unreachable -s $MY_INT -d $ANY -i $IPSEC_IF -j ACCEPT
+#
+## Source quench
+### from/to Internet
+$IPC -A input -p icmp --icmp-type source-quench -s $ANY -d $MY_EXT -i $EXT_IF -j ACCEPT
+$IPC -A output -p icmp --icmp-type source-quench -s $MY_EXT -d $ANY -i $EXT_IF -j ACCEPT
+### from/to Lan
+$IPC -A input -p icmp --icmp-type source-quench -s $ANY -d $MY_INT -i $INT_IF -j ACCEPT
+$IPC -A output -p icmp --icmp-type source-quench -s $MY_INT -d $ANY -i $INT_IF -j ACCEPT
+### from/to Peer Lan
+$IPC -A input -p icmp --icmp-type source-quench -s $ANY -d $MY_INT -i $IPSEC_IF -j ACCEPT
+$IPC -A output -p icmp --icmp-type source-quench -s $MY_INT -d $ANY -i $IPSEC_IF -j ACCEPT
+#
+## Parameter problem
+### from/to Internet
+$IPC -A input -p icmp --icmp-type parameter-problem -s $ANY -d $MY_EXT -i $EXT_IF -j ACCEPT
+$IPC -A output -p icmp --icmp-type parameter-problem -s $MY_EXT -d $ANY -i $EXT_IF -j ACCEPT
+### from/to Lan
+$IPC -A input -p icmp --icmp-type parameter-problem -s $ANY -d $MY_INT -i $INT_IF -j ACCEPT
+$IPC -A output -p icmp --icmp-type parameter-problem -s $MY_INT -d $ANY -i $INT_IF -j ACCEPT
+### from/to Peer Lan
+$IPC -A input -p icmp --icmp-type parameter-problem -s $ANY -d $MY_INT -i $IPSEC_IF -j ACCEPT
+$IPC -A output -p icmp --icmp-type parameter-problem -s $MY_INT -d $ANY -i $IPSEC_IF -j ACCEPT
+#
+## Time To Live exceeded
+### from/to Internet
+$IPC -A input -p icmp --icmp-type time-exceeded -s $ANY -d $MY_EXT -i $EXT_IF -j ACCEPT
+$IPC -A output -p icmp --icmp-type time-exceeded -s $MY_EXT -d $ANY -i $EXT_IF -j ACCEPT
+### to Lan
+$IPC -A input -p icmp --icmp-type time-exceeded -s $ANY -d $MY_INT -i $INT_IF -j ACCEPT
+$IPC -A output -p icmp --icmp-type time-exceeded -s $MY_INT -d $ANY -i $INT_IF -j ACCEPT
+### to Peer Lan
+$IPC -A input -p icmp --icmp-type time-exceeded -s $ANY -d $MY_INT -i $IPSEC_IF -j ACCEPT
+$IPC -A output -p icmp --icmp-type time-exceeded -s $MY_INT -d $ANY -i $IPSEC_IF -j ACCEPT
+
+# ICMP PINGs
+## from Internet
+$IPC -A input -p icmp -s $ANY -d $MY_EXT --icmp-type echo-request  -i $EXT_IF -j ACCEPT
+$IPC -A output -p icmp -s $MY_EXT -d $ANY --icmp-type echo-reply  -i $EXT_IF -j ACCEPT
+## from LAN
+$IPC -A input -p icmp -s $ANY -d $MY_INT --icmp-type echo-request -i $INT_IF -j ACCEPT
+$IPC -A output -p icmp -s $MY_INT -d $ANY --icmp-type echo-reply  -i $INT_IF -j ACCEPT
+## from Peer LAN
+$IPC -A input -p icmp -s $ANY -d $MY_INT --icmp-type echo-request -i $IPSEC_IF -j ACCEPT
+$IPC -A output -p icmp -s $MY_INT -d $ANY --icmp-type echo-reply  -i $IPSEC_IF -j ACCEPT
+
+# SSH
+## from SSH_PEER_HOST
+$IPC -A input -p tcp -s $SSH_PEER_HOST -d $MY_EXT 22 -i $EXT_IF -j ACCEPT
+$IPC -A output -p tcp \! -y -s $MY_EXT 22 -d $SSH_PEER_HOST -i $EXT_IF -j ACCEPT
+## to SSH_PEER_HOST
+$IPC -A input -p tcp \! -y -s $SSH_PEER_HOST 22 -d $MY_EXT -i $EXT_IF -j ACCEPT
+$IPC -A output -p tcp -s $MY_EXT -d $SSH_PEER_HOST 22 -i $EXT_IF -j ACCEPT
+## from PEER
+$IPC -A input -p tcp -s $PEER_EXT -d $MY_EXT 22 -i $EXT_IF -j ACCEPT
+$IPC -A output -p tcp \! -y -s $MY_EXT 22 -d $PEER_EXT -i $EXT_IF -j ACCEPT
+## to PEER
+$IPC -A input -p tcp \! -y -s $PEER_EXT 22 -d $MY_EXT -i $EXT_IF -j ACCEPT
+$IPC -A output -p tcp -s $MY_EXT -d $PEER_EXT 22 -i $EXT_IF -j ACCEPT
+
+# ipxtunnel
+$IPC -A input -p udp -s $PEER_INT 2005 -d $MY_INT 2005 -i $IPSEC_IF -j ACCEPT
+$IPC -A output -p udp -s $MY_INT 2005 -d $PEER_INT 2005 -i $IPSEC_IF -j ACCEPT
+
+---------------- end of rc.firewall ----------------------
+
+To understand this we need to look on this scheme:
+
+           ++-----------------------<----------------------------+
+           || ipsec0                                             |
+           \/                                                    |
+ eth0  +--------+    /---------/ yes  /---------/ yes +-----------------------+
+------>| INPUT  |-->/ ?local? /----->/ ?IPsec? /----->| decrypt decapsulate |
+ eth1  +--------+  /---------/      /---------/       +-----------------------+
+                       || no            || no
+                       \/               \/
+                  +----------+      +---------+        +-------+
+                  | routing  |      |  local  |        | local |
+                  | decision |      | deliver |        | send  |
+                  +----------+      +---------+        +-------+
+                       ||                                 ||
+                       \/                                 \/
+                   +---------+                       +----------+
+                   | forward |                       | routing  |
+                   +---------+                       | decision |
+                       ||                            +----------+
+                       ||                                  ||
+                       ++----------------<-----------------++
+                       ||
+                       \/
+                   +--------+ eth0
+                   | OUTPUT | eth1
+                   +--------+ ipsec0
+                       ||
+                       \/
+                   /---------/ yes +-----------------------+
+                  / ?IPsec? /----->| encrypt encapsulate |
+                 /---------/       +-----------------------+
+                      || no                    ||
+                      ||                       ||
+                      ||                       \/   eth0, eth1
+                      ++-----------------------++-------------->
+
+This explain how a packet traverse TCP/IP stack in IPsec capable kernel.
+
+FIX ME, please, if there are any errors
+
+Test the new firewall now.
+
+
+Now about IPX. I tried 3 programs for tunneling IPX: tipxd, SIB and ipxtunnel
+
+tipxd didn't send packets.. :(
+SIB and ipxtunnel worked fine :)
+With ipxtunnel there was a little problem. In sources there are an error.
+
+--------------------- in main.c ------------------------
+<       bytes += p.len;
+---
+>       bytes += len;
+--------------------------------------------------------
+
+After this FIX everything goes right...
+
+------------------- /etc/ipxtunnel.conf ----------------
+port    2005
+remote  192.168.101.97    2005
+interface eth1
+--------------- end of /etc/ipxtunnel.conf -------------
+
+I use IPX tunnel between .1.1 and .2.10 so we don't need to encrypt nor
+authenticate encapsulated IPX packets, it is done with IPsec.
+
+If you don't wont to use iproute2 to change source IP you need to use SIB
+(it is able to bind local address) or establish tunnel between .0.1 and
+.0.10 (external IPs, you need to do encryption in the program, but it isn't
+strong).
+
+For now I'm using ipxtunnel.
+
+I think that's all for the moment. If there are any error, please e-mail me: 
+poltorak@df.ru . It would be cool if someone puts the scheme of TCP/IP in
+kernel and firewall example on FreeS/WAN's manual pages.
+
+PoltoS
+
+# test-kind     directory-containing-test       expectation     [PR#]
+
+  
+
+reffile   
+
+samplefile
+
+            cd /c2/kernel
+           tar xzvf ../download/pub/linux/kernel/v2.4/linux-2.4.19.tar.gz
+
+
+            mkdir -p /c2/user-mode-linux/basic-root
+           cd /c2/user-mode-linux/basic-root
+           tar xzvf ../download/umlfreeroot-15.1.tar.gz
+
+
+            mkdir -p /c2/freeswan/sandbox
+           cd /c2/freeswan/sandbox
+           tar xzvf ../download/snapshot.tar.gz
+
+
+ 	./configure
+	make
+
+
+ 	./configure
+	make
+	# Need to be superuser to install in system directories.
+	# Installing in ~/bin would be an alternative.
+	su -c "make install"
+
+
+ 	cd tools
+	make all
+	# Need to be superuser to install in system directories.
+	# Installing in ~/bin would be an alternative.
+	su -c "make install BIN_DIR=/usr/local/bin"
+
+
 cd $TESTINGROOT/utils
+sh make-uml.sh
+
     for i in sunrise sunset east west
+    do
+        xterm -name $i -title $i -e $POOLSPACE/$i/start.sh     done
+
+marajade-[projects/freeswan/mgmt/planning] mcr 1029 %ps ax | grep gdb
+ 1659 pts/9    SN     0:00 /usr/bin/gdb -fullname -cd /mara4/freeswan/kernpatch/UMLPOOL/swan/ linux
+
+UML_east_OPT="debug gdb-pid=1659"
+
+marajade-[kernpatch/testing/klips/east-icmp-02] mcr 1220 %../../utils/runme.sh
+
+(gdb) file linux
+Reading symbols from linux...done.
+(gdb) attach 1
+Attaching to program: /mara4/freeswan/kernpatch/UMLPOOL/swan/linux, process 1
+0xa0118bc1 in kill () at hostfs_kern.c:770
+
John Denker wrote:
+
+> Indeed there are several ways in which the documentation overstates the 
+> scope of what this project does -- starting with the name 
+> FreeS/WAN.  There's a big difference between having an encrypted IP tunnel 
+> versus having a Secure Wide-Area Network.  This software does a fine job of 
+> the former, which is necessary but not sufficient for the latter.
+
+The goal of the project is to make it very hard to tap your wide area
+communications.  The current system provides very good protection
+against passive attacks (wiretapping and those big antenna farms).
+Active attacks, which involve the intruder sending packets to your
+system (like packets that break into sendmail and give them a root
+shell :-) are much harder to guard against.  Active attacks that
+involve sending people (breaking into your house and replacing parts
+of your computer with ones that transmit what you're doing) are also
+much harder to guard against.  Though we are putting effort into
+protecting against active attacks, it's a much bigger job than merely
+providing strong encryption.  It involves general computer security,
+and general physical security, which are two very expensive problems
+for even a site to solve, let alone to build into a whole society.
+
+The societal benefit of building an infrastructure that protects
+well against passive attacks is that it makes it much harder to do
+undetected bulk monitoring of the population.  It's a defense against
+police-states, not against policemen.
+
+Policemen can put in the effort required to actively attack sites that
+they have strong suspicions about.  But police states won't be able to
+build systems that automatically monitor everyone's communications.
+Either they will be able to monitor only a small subset of the
+populace (by targeting those who screwed up their passive security),
+or their monitoring activities will be detectable by those monitored
+(active attacks leave packet traces or footprints), which can then be
+addressed through the press and through political means if they become
+too widespread.
+
+FreeS/WAN does not protect very well against traffic analysis, which
+is a kind of widespread police-state style monitoring that still
+reveals significant information (who's talking to who) without
+revealing the contents of what was said.  Defenses against traffic
+analysis are an open research problem.  Zero Knowledge Systems is
+actively deploying a system designed to thwart it, designed by Ian
+Goldberg.  The jury is out on whether it actually works; a lot more
+experience with it will be needed.
  Mary had a little key - she kept it in escrow,
+  and every thing that Mary said,
+  the feds were sure to know.
   Mary had a little key (It's all she could export),
+   and all the email that she sent was opened at the Fort.
        Strong Internet Privacy Software Free for Linux Users Worldwide
+
+Toronto, ON, April 14, 1999 - 
+
+The Linux FreeS/WAN project today released free software to protect
+the privacy of Internet communications using strong encryption codes.
+FreeS/WAN automatically encrypts data as it crosses the Internet, to
+prevent unauthorized people from receiving or modifying it.  One
+ordinary PC per site runs this free software under Linux to become a
+secure gateway in a Virtual Private Network, without having to modify
+users' operating systems or application software.  The project built
+and released the software outside the United States, avoiding US
+government regulations which prohibit good privacy protection.
+FreeS/WAN version 1.0 is available immediately for downloading at
+http://www.xs4all.nl/~freeswan/.
+
+"Today's FreeS/WAN release allows network administrators to build
+excellent secure gateways out of old PCs at no cost, or using a cheap
+new PC," said John Gilmore, the entrepreneur who instigated the
+project in 1996.  "They can build operational experience with strong
+network encryption and protect their users' most important
+communications worldwide."
+
+"The software was written outside the United States, and we do not
+accept contributions from US citizens or residents, so that it can be
+freely published for use in every country," said Henry Spencer, who
+built the release in Toronto, Canada.  "Similar products based in the
+US require hard-to-get government export licenses before they can be
+provided to non-US users, and can never be simply published on a Web
+site.  Our product is freely available worldwide for immediate
+downloading, at no cost."
+
+FreeS/WAN provides privacy against both quiet eavesdropping (such as
+"packet sniffing") and active attempts to compromise communications
+(such as impersonating participating computers).  Secure "tunnels" carry
+information safely across the Internet between locations such as a
+company's main office, distant sales offices, and roaming laptops.  This
+protects the privacy and integrity of all information sent among those
+locations, including sensitive intra-company email, financial transactions
+such as mergers and acquisitions, business negotiations, personal medical
+records, privileged correspondence with lawyers, and information about
+crimes or civil rights violations.  The software will be particularly
+useful to frequent wiretapping targets such as private companies competing
+with government-owned companies, civil rights groups and lawyers,
+opposition political parties, and dissidents. 
+
+FreeS/WAN provides privacy for Internet packets using the proposed
+standard Internet Protocol Security (IPSEC) protocols.  FreeS/WAN
+negotiates strong keys using Diffie-Hellman key agreement with 1024-bit
+keys, and encrypts each packet with 168-bit Triple-DES (3DES).  A modern
+$500 PC can set up a tunnel in less than a second, and can encrypt
+6 megabits of packets per second, easily handling the whole available
+bandwidth at the vast majority of Internet sites.  In preliminary testing,
+FreeS/WAN interoperated with 3DES IPSEC products from OpenBSD, PGP, SSH,
+Cisco, Raptor, and Xedia.  Since FreeS/WAN is distributed as source code,
+its innards are open to review by outside experts and sophisticated users,
+reducing the chance of undetected bugs or hidden security compromises.
+
+The software has been in development for several years.  It has been
+funded by several philanthropists interested in increased privacy on
+the Internet, including John Gilmore, co-founder of the Electronic
+Frontier Foundation, a leading online civil rights group.
+
+Press contacts:
+Hugh Daniel,   +1 408 353 8124, hugh@toad.com
+Henry Spencer, +1 416 690 6561, henry@spsystems.net
+
+* FreeS/WAN derives its name from S/WAN, which is a trademark of RSA Data
+  Security, Inc; used by permission.
       MI1 ---------->
+           <---------- MR1
+       MI2 ----------> 
+           <---------- MR2
+       MI3 ---------->
+           <---------- MR3
When one IKE system (for example, Pluto) is negotiating with another
+to create an SA, the Initiator proposes a bunch of choices and the
+Responder replies with one that it has selected.
+
+The structure of the choices is fairly complicated.  An SA payload
+contains a list of lists of "Proposals".  The outer list is a set of
+choices: the selection must be from one element of this list.
+
+Each of these elements is a list of Proposals.  A selection must be
+made from each of the elements of the inner list.  In other words,
+*all* of them apply (that is how, for example, both AH and ESP can
+apply at once).
+
+Within each of these Proposals is a list of Transforms.  For each
+Proposal selected, one Transform must be selected (in other words,
+each Proposal provides a choice of Transforms).
+
+Each Transform is made up of a list of Attributes describing, well,
+attributes.  Such as lifetime of the SA.  Such as algorithm to be
+used.  All the Attributes apply to a Transform.
+
+You will have noticed a pattern here: layers alternate between being
+disjunctions ("or") and conjunctions ("and").
+
+For Phase 1 / Main Mode (negotiating an ISAKMP SA), this structure is
+cut back.  There must be exactly one Proposal.  So this degenerates to
+a list of Transforms, one of which must be chosen.
                  BEFORE APPLYING AH
+            ----------------------------
+      IPv4  |orig IP hdr  |     |      |
+            |(any options)| TCP | Data |
+            ----------------------------
+
+                  AFTER APPLYING AH
+            ---------------------------------
+      IPv4  |orig IP hdr  |    |     |      |
+            |(any options)| AH | TCP | Data |
+            ---------------------------------
+            ||
+                 except for mutable fields
                         ||
+IPv4  | new IP hdr* |    | orig IP hdr*  |    |      |
+      |(any options)| AH | (any options) |TCP | Data |
+      ------------------------------------------------
+      ||
+      |           in the new IP hdr                  |
        /etc/ipsec.conf
          y      x
+        2^0  ==  1
+        2^1  ==  2
+        2^2  ==  4
+        2^3  ==  8
+        2^4  ==  3 that is, the remainder from 16/13 is 3
+        2^5  ==  6          the remainder from 32/13 is 6
+        2^6  == 12 and so on
+        2^7  == 11
+        2^8  ==  9
+        2^9  ==  5
+        2^10 == 10
+        2^11 ==  7
+        2^12 ==  1
        C = E(k2,E(k1,P))
+        P = D(k1,D(k2,C))
        M = E(k1,P)
+        M = D(k2,C)
        x^p == x         modulo p
+        x^(p-1) == 1     modulo p, non-zero x
+      
        ed == 1          modulo lcm( p-1, q-1)
+      
      x^ed == x           modulo pq
+      
        c = i^e           modulo N
+      
        c^d == (i^e)^d    modulo N
+            == i^ed       modulo N
+            == i          modulo N
+      
RFC#        Title
2401        Security Architecture for the Internet Protocol
+2411        IP Security Document Roadmap
2402        IP Authentication Header
+2406        IP Encapsulating Security Payload (ESP)
2367        PF_KEY Key Management API, Version 2
+2407        The Internet IP Security Domain of Interpretation for ISAKMP
+2408        Internet Security Association and Key Management Protocol (ISAKMP)
+2409        The Internet Key Exchange (IKE)
+2412        The OAKLEY Key Determination Protocol
+2528        Internet X.509 Public Key Infrastructure
2085        HMAC-MD5 IP Authentication with Replay Prevention
+2104        HMAC: Keyed-Hashing for Message Authentication
+2202        Test Cases for HMAC-MD5 and HMAC-SHA-1
+2207        RSVP Extensions for IPSEC Data Flows
+2403        The Use of HMAC-MD5-96 within ESP and AH
+2404        The Use of HMAC-SHA-1-96 within ESP and AH
+2405        The ESP DES-CBC Cipher Algorithm With Explicit IV
+2410        The NULL Encryption Algorithm and Its Use With IPsec
+2451        The ESP CBC-Mode Cipher Algorithms
+2521        ICMP Security Failures Messages
1321        The MD5 Message-Digest Algorithm
+1828        IP Authentication using Keyed MD5
+1829        The ESP DES-CBC Transform
+1851        The ESP Triple DES Transform
+1852        IP Authentication using Keyed SHA
2137        Secure Domain Name System Dynamic Update
+2230        Key Exchange Delegation Record for the DNS
+2535        Domain Name System Security Extensions
+2536        DSA KEYs and SIGs in the Domain Name System (DNS)
+2537        RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
+2538        Storing Certificates in the Domain Name System (DNS)
+2539        Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
2521        ICMP Security Failures Messages
+2522        Photuris: Session-Key Management Protocol
+2523        Photuris: Extended Schemes and Attributes
1750        Randomness Recommendations for Security
+1918        Address Allocation for Private Internets
+1984        IAB and IESG Statement on Cryptographic Technology and the Internet
+2144        The CAST-128 Encryption Algorithm
        ipsec tncfg arguments
        man 8 ipsec_tncfg
+        man 8 ipsec_auto
+
+            cd /c2/kernel
+           tar xzvf ../download/pub/linux/kernel/v2.4/linux-2.4.19.tar.gz
+
+
+            mkdir -p /c2/user-mode-linux/basic-root
+           cd /c2/user-mode-linux/basic-root
+           tar xzvf ../download/umlfreeroot-15.1.tar.gz
+
+
+            mkdir -p /c2/freeswan/sandbox
+           cd /c2/freeswan/sandbox
+           tar xzvf ../download/snapshot.tar.gz
+
+
+ 	./configure
+	make
+
+
+ 	./configure
+	make
+	# Need to be superuser to install in system directories.
+	# Installing in ~/bin would be an alternative.
+	su -c "make install"
+
+
+ 	cd tools
+	make all
+	# Need to be superuser to install in system directories.
+	# Installing in ~/bin would be an alternative.
+	su -c "make install BIN_DIR=/usr/local/bin"
+
+
 cd $TESTINGROOT/utils
+sh make-uml.sh
+
     for i in sunrise sunset east west
+    do
+        xterm -name $i -title $i -e $POOLSPACE/$i/start.sh     done
+
+marajade-[projects/freeswan/mgmt/planning] mcr 1029 %ps ax | grep gdb
+ 1659 pts/9    SN     0:00 /usr/bin/gdb -fullname -cd /mara4/freeswan/kernpatch/UMLPOOL/swan/ linux
+
+UML_east_OPT="debug gdb-pid=1659"
+
+marajade-[kernpatch/testing/klips/east-icmp-02] mcr 1220 %../../utils/runme.sh
+
+(gdb) file linux
+Reading symbols from linux...done.
+(gdb) attach 1
+Attaching to program: /mara4/freeswan/kernpatch/UMLPOOL/swan/linux, process 1
+0xa0118bc1 in kill () at hostfs_kern.c:770
+
+# test-kind     directory-containing-test       expectation     [PR#]
+
+  
+
+reffile   
+
+samplefile
+

Problem	Status	+Action
`ipsec` not on-path		+ Add `/usr/local/sbin` to your PATH. +
Missing KLIPS support	critical +	See this FAQ.
No RSA private key		+ Follow these instructions to + create an RSA key pair for your host. RSA keys are: + + required for opportunistic encryption, and + our preferred method to authenticate pre-configured connections. + +
`pluto` not running	+critical	+ service ipsec start +
No port 500 hole	critical	+Open port 500 for IKE negotiation.
Port 500 check N/A		Check that port 500 is open + for IKE negotiation.
Failed DNS checks		Opportunistic encryption + requires information from DNS. To set this up, see + our instructions.
No public IP address		Check that the interface + which you want to protect with IPSec is up and running.

Symptom	Problem	+Action
You're running FreeS/WAN 2.01 (or later), and initiating a + connection to FreeS/WAN 2.00 (or earlier). In your logs, you see a + message like: + no RSA public key known for '192.0.2.13'; +DNS search for KEY failed (no KEY record +for 13.2.0.192.in-addr.arpa.) + The older FreeS/WAN logs no error.	+ A protocol level incompatibility between 2.01 (or later) and 2.00 + (or earlier) causes this error. It occurs when a FreeS/WAN 2.01 (or + later) box for which no KEY record is posted attempts to initiate an OE + connection to older FreeS/WAN versions (2.00 and earlier). Note that + older versions can initiate to newer versions without this error.	+If you control the peer host, upgrade its FreeS/WAN to 2.01 (or later), + and post new style TXT records for it. If not, but if you know its + sysadmin, perhaps a quick note is in order. If neither option is + possible, you can ease the transition by posting an old style KEY + record (created with a command like "ipsec showhostkey --key") to the + reverse map for the FreeS/WAN 2.01 (or later) box.
OE host is very slow to contact other hosts.	Slow DNS + service while running OE.	It's a good idea to run a caching DNS + server on your OE host, as outlined in + this mailing list message. If your DNS servers are elsewhere, put + their IPs in the `clear` policy group, and re-read groups with + ipsec auto --rereadgroups +
+ Can't Opportunistically initiate for +192.0.2.2 to 192.0.2.3: no TXT record +for 13.2.0.192.in-addr.arpa. +	Peer is not set up for OE.	+ None. Plenty of hosts on the Internet do not run OE. If, however, you + have set OE up on that peer, this may indicate that you need to wait up + to 48 hours for its DNS records to propagate. +
`ipsec verify` does not find DNS records: + ... +Looking for TXT in forward map: + xy.example.com...[FAILED] +Looking for TXT in reverse map...[FAILED] +... + You also experience authentication failure: + + Possible authentication failure: +no acceptable response to our +first encrypted message +	DNS records are not posted or have not propagated.	Did + you post the DNS records necessary for OE? If not, do so using the + instructions in our quickstart guide. If so, + wait up to 48 hours for the DNS records to propagate.
`ipsec verify` does not find DNS records, and you + experience authentication failure.	For iOE, your ID does not + match location of forward DNS record.	In `config setup` +, change `myid=` to match the forward DNS where you posted the + record. Restart FreeS/WAN. For reference, see our + iOE instructions.
`ipsec verify` finds DNS records, yet there is still + authentication failure. ( ? )	DNS records are malformed.	+Re-create the records and send new copies to your DNS administrator.
`ipsec verify` finds DNS records, yet there is still + authentication failure. ( ? )	DNS records show different keys + for a gateway vs. its subnet hosts.	All TXT records for boxes + protected by an OE gateway must contain the gateway's public key. + Re-create and re-post any incorrect records using + these instructions.
OE gateway loses connectivity to its subnet. The gateway's + routing table shows routes to the subnet through IPsec interfaces.	+The subnet is part of the `private` or `block` policy + group on the gateway.	Remove the subnet from the group, and + reread groups with + ipsec auto --rereadgroups +
OE does not work to hosts on the local LAN.	This is a + known issue.	See this list + of known issues with OE.
FreeS/WAN does not seem to be executing your default policy. In + your logs, you see a message like: + /etc/ipsec.d/policies/iprivate-or-clear" +line 14: subnet "0.0.0.0/0", +source 192.0.2.13/32, +already "private-or-clear" +	Fullnet in a policy group file defines + your default policy. Fullnet should normally be present in only one + policy group file. The fine print: you can have two default policies + defined so long as they protect different local endpoints (e.g. the + FreeS/WAN gateway and a subnet).	Find all policies which + contain fullnet with: + + grep -F 0.0.0.0/0 /etc/ipsec.d/policies/* + then remove the unwanted occurrence(s).

Yes	People report that this + works for them.
[Blank]	We don't know.
No	We have reason to + believe it was, at some point, not possible to get this to work.
Partial	Partial success. + For example, a connection can be created from one end only.
Yes/Partial +	Mixed reports.
Maybe	We think the answer + is "yes", but need confirmation.

Interface		Machine speed in MHz
Type	Mbit per + second	Estimate + Mbit*25	Minimum IPSEC gateway	Minimum with other + load + (e.g. firewall) +
DSL	1	25 MHz	+whatever you have	133, or better if you have it
cable modem	3	75 MHz	+whatever you have	133, or better if you have it
any link, light load	+5	125 MHz	133	200+, + almost any surplus machine
Ethernet	10	250 MHz	+surplus 266 or 300	500+
fast link, moderate load	+20	500 MHz	500	800+, + any current off-the-shelf PC
T3 or E3	45	1125 MHz	+1200	1500+
fast Ethernet	100	+2500 MHz	// not feasible + with 3DES in software on current machines //
OC3	155	3875 MHz

ECB	Electronic CodeBook	+encrypt each block independently
CBC	Cipher Block Chaining +	XOR previous block ciphertext into new block plaintext + before encrypting new block
CFB	Cipher FeedBack
OFB	Output FeedBack

1.	192.0.2.11/32	Local start point of the + protected traffic.
2.	192.0.2.194/32	Remote end point of the + protected traffic.
3.	192.0.2.12	Remote FreeS/WAN node (gateway or + host). May be the same as (2).
4.	[not shown]	Local FreeS/WAN node (gateway or + host), where you've produced the output. May be the same as (1).

	FreeS/WAN VPN					Road Warrior	+OE
	PSK	RSA Secret	X.509 + (requires patch)	+NAT-Traversal + (requires patch)	+Manual + Keying
More Compatible
FreeS/WAN	+Yes	Yes +	Yes	+Yes	Yes	+Yes	Yes
isakmpd (OpenBSD) +	Yes		+Yes		Yes		+No
Kame (FreeBSD, + NetBSD, MacOSX) + aka racoon	Yes	Yes	+Yes		+Yes		No
McAfee VPN + was PGPNet	Yes	Yes	+Yes			+Yes	No
Microsoft + Windows 2000/XP	+Yes		Yes		+	Yes	+No
SSH Sentinel	Yes		Yes +	Maybe		+Yes	No
Safenet SoftPK + /SoftRemote	+Yes		Yes		+	Yes	+No
Other
6Wind		+	Yes				+No
Alcatel Timestep +	Yes				+		No
Apple Macintosh + System 10+	+Maybe	Yes	+Maybe		Maybe	+	No
AshleyLaurent + VPCom	+Yes						No
Borderware +	Yes				+	No	+No
Check Point FW-1/VPN-1 +	Yes		+Yes			Yes	+No
Cisco with 3DES	+Yes	Maybe +		Maybe		+	No
Equinux VPN Tracker + (for Mac OS X)	+Yes	Yes	+Yes		Maybe	+	No
F-Secure	+Yes			+Maybe	Yes	+Yes	No
Gauntlet GVPN +	Yes		+Yes				+No
IBM AIX	+Yes		Maybe	+			No
IBM AS/400	Yes					+	No
Intel Shiva + LANRover/Net Structure	+Yes						No
LanCom (formerly ELSA) +	Yes			+			No
Linksys	+Maybe		+No			Yes	+No
Lucent	Partial					+	No
Netasq	+		Yes			+	No
netcelo	+		Yes			+	No
Netgear fvs318 +	Yes				+		No
Netscreen 100 + or 5xp	+Yes					+Maybe	No
Nortel Contivity +	Partial		+Yes	Maybe		+	No
RadGuard	+Yes					+	No
Raptor	Yes				+Yes		No
Redcreek Ravlin +	Yes/Partial +						+No
SonicWall	+Yes				Maybe	No	+No
Sun Solaris	Yes		Yes +		Yes		No
Symantec	+Yes					+	No
Watchguard + Firebox	+Yes				+Yes		No
Xedia Access Point + /QVPN	+Yes						No
Zyxel Zywall + /Prestige	+Yes						No
	PSK	RSA Secret	X.509 + (requires patch)	+NAT-Traversal + (requires patch)	+Manual + Keying
	FreeS/WAN VPN					Road Warrior	+OE

	IPsec	authentication	encryption	+cycles/byte
Linux IP stack alone	no	no	no	+5
IPsec without crypto	yes	no	no	+11
IPsec, authentication only	yes	SHA-1	no	24
IPsec with encryption	yes	yes	yes	not tested

Introduction to FreeS/WAN

The "munitions" archive of Linux crypto software +

Quickstart Guide to Opportunistic Encryption +

Does FreeS/WAN support site-to-site VPN ( +Virtual Private Network) applications?

Does FreeS/WAN support single DES encryption? +

Can I reload connection info without restarting? +

Can I use Quality of Service routing with FreeS/WAN? +