[Openswan Users] Configuration file parser does not support modp specifier for ike parameter

[Steve Lanser]

Greetings Paul et. al.,

I'm new to this forum.  I've recently begun testing Openswan 2.6.21 (on
CentOS, 2.6.18), and I've discovered what looks to be a longstanding bug in
the parser (or in the documentation), namely that it fails to support
";modpXXXX" syntax in the ike parameter, as stated in the ipsec.conf man
page:

       ike    IKE encryption/authentication algorithm to be used for the connection (phase 1 aka ISAKMP SA).
              The format is "cipher-hash;modpgroup, cipher-hash;modpgroup, ..."  Any left out option will be
              filled in with all allowed default options. Multiple proposals are seperated by a comma. If an
              ike= line is specified, no other received proposals will be accepted. Formerly there was a
              distinction (by using a "!"  symbol) between "strict mode" or not. That mode has been obsoleted.
              If an ike= option is specified, the mode is always strict, meaning no other received proposals
              will be accepted. Some examples are ike=3des-sha1,aes-sha1, ike=aes, ike=aes128-md5;modp2048,
              ike=3des-md5;modp1024,esp=aes-sha1;modp1536 or ike=modp1536. The options must be suitable as a
              value of ipsec_spi(8)'s --ike option. The default is to use IKE, and to allow all combinations
              of:

                              cipher:                 3des or aes
                              hash:                   sha1 or md5
                              pfsgroup (DHgroup):     modp1024 or modp1536

In short, the parser appears simply to reject the semicolon suffix syntax
component altogether, and issues, for example, an error like this:

pluto[31725]: esp string error: Non alphanum or valid separator found in auth string, just after "3des-sha1" (old_state=ST_AA)

for the ipsec.conf configuration parameter:

    ike = 3des-sha1;modp1024

However the same syntax works fine for phase 2:

    phase2alg = 3des-sha1;modp1024

With this setting for phase2 I can establish a working connection as long
as I omit the modp setting for IKE (inheriting the default).

This is probably the same issue as this one reported in your bug database:
https://gsoc.xelerance.com/issues/1061
Note that the error above is followed by a subsequent ipsec__plutorun error
of the form:

    ipsec__plutorun: 021 no connection named {connection-name}

One user appears to have identified a fix for this (I haven't tried it yet
but it looks plausible based on my read of the source code):

http://permalink.gmane.org/gmane.network.openswan.devel/1943

Are you aware of this problem, and is there a workaround (I couldn't find
one) or a fix planned for it?

Thanks,

Steve Lanser