[Openswan Users] VPN between two NATed computers, error: cannot IPSec SA; no connection is known

Steven Schlansker stevenschlansker at sbcglobal.net
Tue Dec 13 16:04:56 CET 2005


Hello there,
I am trying to set up an OpenSWAN server on a home network so that when 
I am out of the area I can VPN in and use my computer as if it were on 
the local network.  I have installed OpenSWAN 2.4.0 from the Ubuntu 
packages, and configured it as follows:

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup
         interfaces=%defaultroute
         nat_traversal=yes
 
virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.0.0/24

conn L2TP-PSK
         pfs=no
         authby=secret
         keyingtries=3
         left=192.168.0.11
         right=%any
         leftrsasigkey=%cert
         rightrsasigkey=%cert
         auto=add
         leftprotoport=17/1701
         rightprotoport=17/%any
         rightsubnet=vhost:%no,%priv


#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf

Upon running it, I get:

Dec 13 15:41:27 localhost pluto[25673]: loading secrets from 
"/etc/ipsec.secrets"
Dec 13 15:41:27 localhost pluto[25673]:   loaded private key file 
'/etc/ipsec.d/private/servage.stevenschlansker.dyndns.org.key' (5063 bytes)
Dec 13 15:41:28 localhost pluto[25673]: packet from 69.237.215.125:500: 
ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
Dec 13 15:41:28 localhost pluto[25673]: packet from 69.237.215.125:500: 
ignoring Vendor ID payload [FRAGMENTATION]
Dec 13 15:41:28 localhost pluto[25673]: packet from 69.237.215.125:500: 
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set 
to=106
Dec 13 15:41:28 localhost pluto[25673]: packet from 69.237.215.125:500: 
ignoring Vendor ID payload [Vid-Initial-Contact]
Dec 13 15:41:28 localhost pluto[25673]: "L2TP-PSK"[1] 69.237.215.125 #1: 
responding to Main Mode from unknown peer 69.237.215.125
Dec 13 15:41:28 localhost pluto[25673]: "L2TP-PSK"[1] 69.237.215.125 #1: 
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Dec 13 15:41:28 localhost pluto[25673]: "L2TP-PSK"[1] 69.237.215.125 #1: 
STATE_MAIN_R1: sent MR1, expecting MI2
Dec 13 15:41:29 localhost pluto[25673]: "L2TP-PSK"[1] 69.237.215.125 #1: 
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: both are NATed
Dec 13 15:41:29 localhost pluto[25673]: "L2TP-PSK"[1] 69.237.215.125 #1: 
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Dec 13 15:41:29 localhost pluto[25673]: "L2TP-PSK"[1] 69.237.215.125 #1: 
STATE_MAIN_R2: sent MR2, expecting MI3
Dec 13 15:41:29 localhost pluto[25673]: "L2TP-PSK"[1] 69.237.215.125 #1: 
Main mode peer ID is ID_FQDN: '@echoes'
Dec 13 15:41:29 localhost pluto[25673]: "L2TP-PSK"[2] 69.237.215.125 #1: 
deleting connection "L2TP-PSK" instance with peer 69.237.215.125 
{isakmp=#0/ipsec=#0}
Dec 13 15:41:29 localhost pluto[25673]: "L2TP-PSK"[2] 69.237.215.125 #1: 
I did not send a certificate because I do not have one.
Dec 13 15:41:29 localhost pluto[25673]: "L2TP-PSK"[2] 69.237.215.125 #1: 
transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Dec 13 15:41:29 localhost pluto[25673]: | NAT-T: new mapping 
69.237.215.125:500/13091)
Dec 13 15:41:29 localhost pluto[25673]: "L2TP-PSK"[2] 69.237.215.125 #1: 
STATE_MAIN_R3: sent MR3, ISAKMP SA established 
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha 
group=modp2048}
Dec 13 15:41:29 localhost pluto[25673]: "L2TP-PSK"[2] 69.237.215.125 #1: 
cannot respond to IPsec SA request because no connection is known for 
70.132.67.128/32===192.168.0.11:17/1701...69.237.215.125[@echoes]:17/%any
Dec 13 15:41:29 localhost pluto[25673]: "L2TP-PSK"[2] 69.237.215.125 #1: 
sending encrypted notification INVALID_ID_INFORMATION to 
69.237.215.125:13091
Dec 13 15:41:30 localhost pluto[25673]: "L2TP-PSK"[2] 69.237.215.125 #1: 
Quick Mode I1 message is unacceptable because it uses a previously used 
Message ID 0xd56d8c3f (perhaps this is a duplicated packet)
Dec 13 15:41:30 localhost pluto[25673]: "L2TP-PSK"[2] 69.237.215.125 #1: 
sending encrypted notification INVALID_MESSAGE_ID to 69.237.215.125:13091
Dec 13 15:41:31 localhost pluto[25673]: "L2TP-PSK"[2] 69.237.215.125 #1: 
received Delete SA payload: deleting ISAKMP State #1
Dec 13 15:41:31 localhost pluto[25673]: "L2TP-PSK"[2] 69.237.215.125: 
deleting connection "L2TP-PSK" instance with peer 69.237.215.125 
{isakmp=#0/ipsec=#0}

The problem appears to be that it checks the 'left' side of the 
connection disagrees about the IP.  The internal server is running on 
192.168.0.11, but sees that the external machine addressed the 
connection to 70.132.67.128, so it drops it.  I've tried various 
combinations of left=%any, right=%any (even both at the same time) and 
using leftid, rightid, leftsubnet, etc...

Nothing has worked.  After searching for workarounds for hours, there 
appears to be a patch for exactly this. 
(http://lists.strongswan.org/pipermail/users/2005-February/000645.html) 
  However, the patch must be against a very different version - the 
patch starts at a line past the end of the file, and after searching the 
sources for a block of code looking like what it was trying to patch I 
could not find it.

Do I really need to patch the sources for this?  Is there a newer 
version of the patch?  Or am I missing some really obvious configuration 
directive (the manpages and wiki were not helpful for this)

One unrelated question - I turned on preshared secret authentication 
because I could not get anywhere with certificates.  I created a CA and 
certificates for all my machines - 4096 bits, used the CA.sh script. 
The server totally ignored any requests from a machine using a 
certificate, but upon switching to shared secrets it woke up and gave me 
the error messages.  I found a site saying that any keys over 1024 bits 
will not work.  Is this still true in 2.4.0?  If so, there really ought 
to be a warning somewhere...  If not, then I'll have another question to 
ask after I get this type of authentication working ;)


Thank you very much for any suggestions!
Steven Schlansker


More information about the Users mailing list