[strongSwan-dev] [patch] nat-traversal "bad ietf draft"

[Luke Leighton]

[please cc replies direct to me as well, thanks, am subscribed
"read-only" to this list]

the saga of getting raven-xe devices from sierra wireless to talk
ipsec, any ipsec, continues.  after running a very similar setup from
a desktop system with PSK and FQDNs, and managed to prove to myself at
least that i am sufficiently competent [on a repeated enough
random-attempts basis] to have eventually hit on a correct
configuration.

i then got the ravens to connect using the exact same configuration
and they're sending ISAKMP_XCHG_INFO at the exact point when the
desktop system sends ISAKMP_XCHG_IDPROT.  strongswan not having this
state in its tables at that point chokes.

if i remove the FQDNs and use IP address-based PSK authentication then
everything works.... but *only with one raven* because, obviously,
when the 2nd one connects, there's no way to distinguish it from the
1st one and consequently the 1st one gets disconnected.

so... i *have* to get this working.

log file is at http://hands.com/~lkcl/strongswan.raven.pluto.fail.log
- general rule applying "don't send log crap to mailing lists" being
respected here, config file on the other hand is short enough.

suggestions welcome including going back in the history of strongswan
source code to a suitable date - however many years it takes - when it
was implementing whatever ipsec drafts existed at the time.  we've
already established that the ravens implement almost-the-same ipsec
draft as MacOSX used to.

l.

conn office
        authby=psk
        keyexchange=ikev1
        leftid=@ipsec.lkcl.net
        left=217.147.94.19
        leftsubnet=10.11.12.0/24
        leftfirewall=yes
        rightid=@ftph-user-test.lkcl.net
        rightsubnet=192.168.13.0/24
        rightnexthop=192.168.13.31
        auto=add