More on nm-OpenSwan

[steve <keyhman gmail com>]

Hi,

I'm working on this in my spare time so I apologize if this update seems 
delayed.

First, because nm-openswan depends on it for now, I'll explain and post 
my changes to the openswan init script.

In FC6, by convention, custom IPsec definitions are stored on a 
per-connection basis in files named <conn>.conf in /etc/ipsec.d
I've extended that same convention by adding the need for a 
corresponding <conn>.secrets file which consists of the following 
formatted data:

<WhiteSpace><RemoteGateway>: <TypeIdentifier><WhiteSpace>"<Key>"

Example:
vpn.mydomain.org: PSK "MyFirstPreSharedKey!"

I will add support for certificates later (I don't use them myself).

here's my patch to the init script, diff'd from the distro default:

<code>
--- ipsec    2007-03-10 12:04:08.000000000 -0500
+++ ipsec.new    2007-03-10 12:08:41.000000000 -0500
@@ -39,7 +39,6 @@
# Check that we are root ... so non-root users stop here
[ `id -u` = 0 ] || exit 1

-
me='ipsec setup'        # for messages

syslog ()
@@ -138,6 +137,33 @@

prog="IPsec"

+
+gen_secrets()
+{
+    # generate /etc/ipsec.secrets from /etc/ipsec.d/*.secrets
+
+    filter=`ip route show |grep default |cut -f 3 -d ' '|cut -d '.' -f 
1,2,3`;
+    if_ip=`/sbin/ifconfig -a |grep $filter |cut -d ':' -f 2 |cut -f 1 
-d ' '`;
+
+    for i in /etc/ipsec.d/*.secrets;
+    do (
+        echo -n "$if_ip" >> /etc/ipsec.secrets;
+        cat $i >>/etc/ipsec.secrets;
+    )
+    done;
+    return 0;
+}
+
+reset_secrets()
+{
+    rm -f /etc/ipsec.secrets;
+    echo "# DO NOT EDIT THIS FILE" >>/etc/ipsec.secrets;
+    echo "# This file is re-generated everytime the IPsec subsystem 
restarts." >>/etc/ipsec.secrets;
+    echo "# Secrets should be stored in /etc/ipsec.d/*.secrets" >> 
/etc/ipsec.secrets;
+
+    return 0;
+}
+
# do it
start_it()
{
@@ -153,12 +179,15 @@

case "$1" in
  start|--start|_autostart)
+    reset_secrets;
+    gen_secrets;
    start_it $1;
    RETVAL=$?;
    ;;

  stop|--stop|_autostop)
    stop_it $1;
+    reset_secrets;
    RETVAL=$?;
        ;;

@@ -174,6 +203,8 @@

  restart|--restart|force-reload)
    stop_it stop
+    reset_secrets;
+    gen_secrets;
    start_it start
        RETVAL=$?
    ;;
</code>

This is a simple automation that fixed a problem I had with reliably 
running multiple ipsec tunnels at the same time.

Now on to nm-openswan. I started with the nm-vpc code base as a guide to 
how the plugin is written and needs to function.

I've re-written the Properties GUI to be suitable to configuring IPsec 
connections, and currently need to finish coding the callback handlers.

Here's how I'm approaching this plugin development thus far (feel free 
to correct / advise me):

nm-openswan will depend on a working installation of openswan and all 
it's dependancies.
|-> I've modified the init script for openswan that comes with FC6 to 
automate the startup procedure:
      reason: matching with %any isn't reliable in my experience. 
auto-generating 1-to-1 matches using the IP of the nic that's assigned 
to %defaultroute proved much more reliable (100%) when managing multiple 
IPsec connections.

Everytime the default interface changes, the ipsec service needs to be 
refreshed, which means nm-openswan needs to restart the ipsec service: 
/etc/init.d/ipsec restart

Everytime a new IPsec connection is defined, the ipsec service needs to 
be refreshed to pickup the new connection:
/etc/init.d/ipsec restart

nm-openswan will need to be able to start the openswan service if it's 
not running, restart it if a new connection has been added, or one has 
been deleted, or one has been modified (to refresh the configs). The 
Service CANNOT be started before a network connection has been 
established (ie: %defaultroute exists)

Once the service is up, the connections defined in /etc/ipsec.d should 
be listed by name under the VPN Connections sub-menu, perhaps with the 
identifier "IPsec: " preceeding it for clarity.

The Disconnect VPN functionality may have to change somewhat to 
accomidate multiple, simultaneous IPsec tunnels. A chooser to allow the 
selection of which connection to bring down is "too much" in my mind and 
deviates from the simplistic nature of the NetworkManager UI.

Instead I was thinking of a "toggle" widget next to the Connection Name, 
allowing it to be toggled On/Off.

At the moment, I'm working on understanding and Coding up the functions 
for controlling the ipsec service and eventually, up-ing/down-ing 
individual connections.

I'm having a hard time finding a good explaination on the concepts of 
how the seperate nm components use DBus.
I could use a good explaination or pointer to some docs on how it all 
comes together conceptually.

Some specific questions I have:

How can I display the status of an SA negotiation in progress?

on the command line, I type: ipsec auto --up connectionname <ENTER>
and the output is streamed to the console as it negotiates the 
connection. I believe I need to capture this output and parse as it 
streams in, "grep'ing" for specific control codes that signify different 
stages of the negotiation, which can be used in turn to update the 
connection State.

Once an SA has been established, a control code of 004 is returned to 
the console. This code will be sent twice on a successful connect:

1. ISAKMP SA established (key exchange)
2. IPsec SA established (tunnel)

Once a connection is up, montioring it becomes the trick. From the 
command line, I use the command:

ipsec auto --status |grep -i estabalished to get a list of active SA's.

How can I turn that into a "watch" on the SA such that any change from 
the output will force a state change on the connection to be handled?

Can anyone suggest a better way to monitor the state?

Ideas I've rejected already:
1. call the ipsec |grep every 5 seconds in a loop
2. Poll the routing table for the corresponding route entry for the 
remote network every 5 seconds

If there was a /proc file or some other file I could watch for a size / 
mod time change I could respond to that trigger to update the state 
information but I haven't found one relevant to this problem yet. Any 
suggestions are welcome ;)

That's all for now. I'm coding all weekend so I'll look for replies.

Thanks,

Steve.