[Openswan Users]

Brett Curtis dashnu at gmail.com
Mon Mar 20 08:00:52 CET 2006 

Hi
On Mar 19, 2006, at 4:07 PM, Gilion Goudsmit wrote:

> First of all, thanks for replying!
>
> Jacco de Leeuw wrote:
>> Gilion Goudsmit wrote:
>>
>>
>>> I'm trying to connect my OS/X Tiger client (IPSEC/L2TP) to an  
>>> OpenSwan
>>> server running on my Linux box. The server is running OpenSwan  
>>> 2.4.5rc4,
>>> on internal address 192.168.0.4. By NAT'ing router forwards UDP  
>>> 450 and
>>> 4500 to the Linux server. The OS/X client has as internal address  
>>> in the
>>> 192.168.1.0 network. I'm trying to connect using PSK (to begin  
>>> with at
>>> least)...
>>>
>> I'm not sure if PSKs work with NAT-T.
>>
>>
> :-(
>
> Guess I'll start figuring out certificates then.

I have PSK's working with NAT-T for Windows and OSX. however I do  
lose my connection with OSX every ~30 minutes or so. Could be related.
Also my Openswan Server is the NAT Box.
>
>>> virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,% 
>>> 4:172.16.0.0/12,!%v4:192.168.0.0/24
>>>
>> There are some typos in this line. It should be:
>> virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,% 
>> v4:172.16.0.0/12,%v4:!192.168.0.0/24
>>
>>
> Fixed them both. Indeed I missed the line saying he was ignoring  
> the line because of typos.
>>> conn L2TP-PSK
>>>                 leftnexthop=
>>>
>> This line is incomplete.
>>
>>
> I removed it... I had read somewhere it should be there but left  
> empty in some circumstances...
>>> ===== ipsec.secrets
>>> 192.168.0.4 %any: PSK "mysecret"
>>>
>> Also try 192.168.0.4 : PSK "mysecret"
>>
> Added it...

If your openswan box is the top-level box it should have the external  
IP in the secrets. If not ignore this comment :)
>>
>>> I think my problem is with the line that says:
>>> cannot respond to IPsec SA request because no connection is known  
>>> for
>>> 62.194.118.198/32===192.168.0.4:17/1701...84.18.8.145 
>>> [192.168.1.13]:17/%any===192.168.1.13/32
>>>
>> You should have seen other errors in your logs because of the
>> issues mentioned above.
>>
>> Jacco
>>
>
> I did, but only one... Below my full log for a connection  
> attempt... (still without certificates though). It still seems like  
> the same error is the one stopping the rest of the process...  
> What's the best place to look for 'full' docs on the semantics of  
> left/right stuff and specifically nat traversal and OpenSwan's  
> configuration for it?
>
> Thanks, and regards, Giel (log follows)
>
> Mar 19 22:00:01 gimli ipsec__plutorun: Starting Pluto subsystem...
> Mar 19 22:00:01 gimli pluto[29709]: Starting Pluto (Openswan  
> Version 2.4.5rc4 X.509-1.5.4 PLUTO_SENDS_VENDORID PLUTO
> _USES_KEYRR; Vendor ID OEd|k]dnjtCG)
> Mar 19 22:00:01 gimli pluto[29709]: Setting NAT-Traversal port-4500  
> floating to on
> Mar 19 22:00:01 gimli pluto[29709]:    port floating activation  
> criteria nat_t=1/port_fload=1
> Mar 19 22:00:01 gimli pluto[29709]:   including NAT-Traversal patch  
> (Version 0.6c)
> Mar 19 22:00:01 gimli pluto[29709]: ike_alg_register_enc():  
> Activating OAKLEY_AES_CBC: Ok (ret=0)
> Mar 19 22:00:01 gimli pluto[29709]: starting up 1 cryptographic  
> helpers
> Mar 19 22:00:01 gimli pluto[29709]: started helper pid=29710 (fd:6)
> Mar 19 22:00:01 gimli pluto[29709]: Using Linux 2.6 IPsec interface  
> code on 2.6.9-22.0.2.EL
> Mar 19 22:00:01 gimli pluto[29709]: Could not change to directory '/ 
> etc/ipsec.d/cacerts'
> Mar 19 22:00:01 gimli pluto[29709]: Could not change to directory '/ 
> etc/ipsec.d/aacerts'
> Mar 19 22:00:01 gimli pluto[29709]: Could not change to directory '/ 
> etc/ipsec.d/ocspcerts'
> Mar 19 22:00:01 gimli pluto[29709]: Could not change to directory '/ 
> etc/ipsec.d/crls'
> Mar 19 22:00:01 gimli pluto[29709]: added connection description  
> "L2TP-PSK"
> Mar 19 22:00:01 gimli pluto[29709]: listening for IKE messages
> Mar 19 22:00:01 gimli pluto[29709]: adding interface eth0/eth0  
> 192.168.0.4:500
> Mar 19 22:00:01 gimli pluto[29709]: adding interface eth0/eth0  
> 192.168.0.4:4500
> Mar 19 22:00:01 gimli pluto[29709]: adding interface lo/lo  
> 127.0.0.1:500
> Mar 19 22:00:01 gimli pluto[29709]: adding interface lo/lo  
> 127.0.0.1:4500
> Mar 19 22:00:01 gimli pluto[29709]: adding interface lo/lo ::1:500
> Mar 19 22:00:01 gimli pluto[29709]: loading secrets from "/etc/ 
> ipsec.secrets"
>
>
> Mar 19 22:00:22 gimli pluto[29709]: packet from 84.18.26.248:500:  
> received Vendor ID payload [RFC 3947] method set t
> o=109
> Mar 19 22:00:22 gimli pluto[29709]: packet from 84.18.26.248:500:  
> received Vendor ID payload [draft-ietf-ipsec-nat-t
> -ike] method set to=110
> Mar 19 22:00:22 gimli pluto[29709]: packet from 84.18.26.248:500:  
> received Vendor ID payload [draft-ietf-ipsec-nat-t
> -ike-02] meth=107, but already using method 110
> Mar 19 22:00:22 gimli pluto[29709]: packet from 84.18.26.248:500:  
> received Vendor ID payload [draft-ietf-ipsec-nat-t
> -ike-02_n] meth=106, but already using method 110
> Mar 19 22:00:22 gimli pluto[29709]: "L2TP-PSK"[1] 84.18.26.248 #1:  
> responding to Main Mode from unknown peer 84.18.2
> 6.248
> Mar 19 22:00:22 gimli pluto[29709]: "L2TP-PSK"[1] 84.18.26.248 #1:  
> transition from state STATE_MAIN_R0 to state STAT
> E_MAIN_R1
> Mar 19 22:00:22 gimli pluto[29709]: "L2TP-PSK"[1] 84.18.26.248 #1:  
> STATE_MAIN_R1: sent MR1, expecting MI2
> Mar 19 22:00:23 gimli pluto[29709]: "L2TP-PSK"[1] 84.18.26.248 #1:  
> ignoring Vendor ID payload [KAME/racoon]
> Mar 19 22:00:23 gimli pluto[29709]: "L2TP-PSK"[1] 84.18.26.248 #1:  
> NAT-Traversal: Result using RFC 3947 (NAT-Travers
> al): both are NATed
> Mar 19 22:00:23 gimli pluto[29709]: "L2TP-PSK"[1] 84.18.26.248 #1:  
> transition from state STATE_MAIN_R1 to state STAT
> E_MAIN_R2
> Mar 19 22:00:23 gimli pluto[29709]: "L2TP-PSK"[1] 84.18.26.248 #1:  
> STATE_MAIN_R2: sent MR2, expecting MI3
> Mar 19 22:00:23 gimli pluto[29709]: "L2TP-PSK"[1] 84.18.26.248 #1:  
> Main mode peer ID is ID_IPV4_ADDR: '192.168.11.10
> '
> Mar 19 22:00:23 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> deleting connection "L2TP-PSK" instance with peer
>  84.18.26.248 {isakmp=#0/ipsec=#0}
> Mar 19 22:00:23 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> I did not send a certificate because I do not hav
> e one.
> Mar 19 22:00:23 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> transition from state STATE_MAIN_R2 to state STAT
> E_MAIN_R3
> Mar 19 22:00:23 gimli pluto[29709]: | NAT-T: new mapping  
> 84.18.26.248:500/54422)
> Mar 19 22:00:23 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> STATE_MAIN_R3: sent MR3, ISAKMP SA established {a
> uth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha  
> group=modp1024}
> Mar 19 22:00:23 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> cannot respond to IPsec SA request because no con
> nection is known for  
> 62.194.118.198/32===192.168.0.4:17/1701...84.18.26.248 
> [192.168.11.10]:17/%any===192.168.11.10/3
> 2
> Mar 19 22:00:23 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_ID_INFORMA
> TION to 84.18.26.248:54422
> Mar 19 22:00:26 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it
> uses a previously used Message ID 0x5d20691d (perhaps this is a  
> duplicated packet)
> Mar 19 22:00:26 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID
>  to 84.18.26.248:54422
> Mar 19 22:00:29 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it
> uses a previously used Message ID 0x5d20691d (perhaps this is a  
> duplicated packet)
> Mar 19 22:00:29 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID
>  to 84.18.26.248:54422
> Mar 19 22:00:32 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it
> uses a previously used Message ID 0x5d20691d (perhaps this is a  
> duplicated packet)
> Mar 19 22:00:32 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID
>  to 84.18.26.248:54422
> Mar 19 22:00:35 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it
> uses a previously used Message ID 0x5d20691d (perhaps this is a  
> duplicated packet)
> Mar 19 22:00:35 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID
>  to 84.18.26.248:54422
> Mar 19 22:00:38 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it uses a previously  
> used Message ID 0x5d20691d (perhaps this is a duplicated packet)
> Mar 19 22:00:38 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID to  
> 84.18.26.248:54422
> Mar 19 22:00:41 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it uses a previously  
> used Message ID 0x5d20691d (perhaps this is a duplicated packet)
> Mar 19 22:00:41 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID to  
> 84.18.26.248:54422
> Mar 19 22:00:45 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it uses a previously  
> used Message ID 0x5d20691d (perhaps this is a duplicated packet)
> Mar 19 22:00:45 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID to  
> 84.18.26.248:54422
> Mar 19 22:00:47 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it uses a previously  
> used Message ID 0x5d20691d (perhaps this is a duplicated packet)
> Mar 19 22:00:47 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID to  
> 84.18.26.248:54422
> Mar 19 22:00:50 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it uses a previously  
> used Message ID 0x5d20691d (perhaps this is a duplicated packet)
> Mar 19 22:00:50 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID to  
> 84.18.26.248:54422
> Mar 19 22:00:57 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> cannot respond to IPsec SA request because no connection is known  
> for 62.194.118.198/32===192.168.0.4:17/1701...84.18.26.248 
> [192.168.11.10]:17/%any===192.168.11.10/32
> Mar 19 22:00:57 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_ID_INFORMATION to  
> 84.18.26.248:54422
> Mar 19 22:01:00 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it uses a previously  
> used Message ID 0x7bfdbba1 (perhaps this is a duplicated packet)
> Mar 19 22:01:00 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID to  
> 84.18.26.248:54422
> Mar 19 22:01:03 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it uses a previously  
> used Message ID 0x7bfdbba1 (perhaps this is a duplicated packet)
> Mar 19 22:01:03 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID to  
> 84.18.26.248:54422
> Mar 19 22:01:06 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it uses a previously  
> used Message ID 0x7bfdbba1 (perhaps this is a duplicated packet)
> Mar 19 22:01:06 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID to  
> 84.18.26.248:54422
> Mar 19 22:01:09 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it uses a previously  
> used Message ID 0x7bfdbba1 (perhaps this is a duplicated packet)
> Mar 19 22:01:09 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID to  
> 84.18.26.248:54422
> Mar 19 22:01:12 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it uses a previously  
> used Message ID 0x7bfdbba1 (perhaps this is a duplicated packet)
> Mar 19 22:01:12 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID to  
> 84.18.26.248:54422
> Mar 19 22:01:15 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it uses a previously  
> used Message ID 0x7bfdbba1 (perhaps this is a duplicated packet)
> Mar 19 22:01:15 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID to  
> 84.18.26.248:54422
> Mar 19 22:01:18 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it uses a previously  
> used Message ID 0x7bfdbba1 (perhaps this is a duplicated packet)
> Mar 19 22:01:18 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID to  
> 84.18.26.248:54422
> Mar 19 22:01:21 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> Quick Mode I1 message is unacceptable because it uses a previously  
> used Message ID 0x7bfdbba1 (perhaps this is a duplicated packet)
> Mar 19 22:01:21 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> sending encrypted notification INVALID_MESSAGE_ID to  
> 84.18.26.248:54422
> Mar 19 22:01:22 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248 #1:  
> received Delete SA payload: deleting ISAKMP State #1
> Mar 19 22:01:22 gimli pluto[29709]: "L2TP-PSK"[2] 84.18.26.248:  
> deleting connection "L2TP-PSK" instance with peer 84.18.26.248  
> {isakmp=#0/ipsec=#0}
> Mar 19 22:01:22 gimli pluto[29709]: packet from 84.18.26.248:54422:  
> received and ignored informational message

Here is a snip of my config as it relates to OSX.

config setup
        interfaces=%defaultroute
        klipsdebug=none
        plutodebug=none
        overridemtu=1410
        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.1.0/24

conn %default
         keyingtries=3
         compress=no
         disablearrivalcheck=no
         type=tunnel
         keyexchange=ike
         ikelifetime=240m
         keylife=60m

conn roadwarrior-osx
         authby=secret
         leftprotoport=17/1701
         rightprotoport=17/%any
         also=roadwarrior

conn roadwarrior
         pfs=no
         left=%defaultroute
         right=%any
         rightsubnet=vhost:%no,%priv
         auto=add

Maybe that will help you.. I just changed my config and have not  
restarted the daemon yet but I am pretty sure this will fly. The book  
has an area that says right=%any and left=%defaultroute can not be  
used in the same connection, this confuses me a bit but my last  
configuration worked this way. Unless this just implies both ends of  
the connection.

Brett
>
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327? 
> n=283155

More information about the Users mailing list