[Openswan Users] Site-to-site VPN with openswan

Jakub Sobczak sopel1000 at gmail.com
Wed Aug 29 04:45:46 EDT 2012


Hi,

tcpdump shows:

 10:37:17.007960 IP remote-ip.500 >  my-ip.500 : isakmp: phase 1 I ident
> 10:37:17.008104 IP my-ip.500 >  remote-ip.500 : isakmp: phase 1 R inf


I do not know where this .500 comes from, it looks like this: 1.2.3.4.500,
but anyway it seems fine. What worries me however is:

104 "conn" #1806: STATE_MAIN_I1: initiate
> 003 "conn" #1806: received Vendor ID payload [Dead Peer Detection]
> 003 "conn" #1806: ignoring unknown Vendor ID payload
> [699369228741c6d4ca094c93e242c9de19e7b7c60000000500000500]
> 003 "conn" #1806: Can't authenticate: no preshared key found for `my-ip'
> and `remote-ip'.  Attribute OAKLEY_AUTHENTICATION_METHOD
> 003 "conn" #1806: no acceptable Oakley Transform
> 214 "conn" #1806: STATE_MAIN_I1: NO_PROPOSAL_CHOSEN


Again, my ipsec.secrets looks like this (copy-paste):

my-ip remote-ip : PSK "some-presharedkey"


What is going on? Maybe I have to install something?

Regards,
Jakub



2012/8/29 Roel van Meer <roel.vanmeer at bokxing.nl>

> Jakub Sobczak writes:
>
>  Yes, the shared key line is formatted in the following way:  1.2.3.4 <URL:
>> http://5.6.7.8/>5**.6.7.8 <http://5.6.7.8>: PSK "sharedkey" .
>>  I changed auto=add to auto=start hoping it would help, but it didn't:
>>
>>    ipsec auto --up conn
>>    104 "conn" #1616: STATE_MAIN_I1: initiate
>>    010 "conn" #1616: STATE_MAIN_I1: retransmission; will wait 20s for
>>  response
>>    010 "conn" #1616: STATE_MAIN_I1: retransmission; will wait 40s for
>>  response
>>    031 "conn" #1616: max number of retransmissions (2) reached
>>  STATE_MAIN_I1.  No response (or no acceptable response) to our first
>>  IKE message
>>
>
> The other side is not responding. Your firewall might not be set up
> correctly. Can you see anything in the logs that indicate the other side is
> trying to make a connection? If not, you could try to see if there is
> traffic coming in from the other side.
>
> With a command like
> tcpdump -nli eth0 host 1.2.3.4
> (assuming eth0 is the network device of your internet connection, and
> replacing 1.2.3.4 by the ip address of the remote endpoint) you can see
> what is happening on the wire.
> Can you try to start the connection while running the tcpdump command and
> post its output?
>
>
>  I'm not sure if that's correct: ike=aes256-sha1-**modp1536, but if they
>> say: Key Exchange Encryption: AES256  Data integrity: SHA1 and DH group 5,
>> do you think this line is not correct (ike=aes256-sha1-modp1536)? I cannot
>> influence that, I have to adjust...
>> I am using: Linux Openswan U2.6.23/K2.6.32-31-server (netkey) Maybe the
>> problem is that I am not using certificates but psk?
>>
>
> The config details say the you need to use a shared key, so I assume the
> problem is not related to certificates.
>
>
>  How do I check if I  can use klips (which I believe I should use instead
>> of netkey).
>>
>
> You are already using klips, since you have this in your config:
> protostack=klips
>
> Regards,
>
> Roel
>
>
>
>>
>>
>> Kind regards,
>> Jakub
>>
>>
>>
>> 2012/8/29 Roel van Meer <<URL:mailto:roel.vanmeer@**bokxing.nl<roel.vanmeer at bokxing.nl>
>> >roel.vanmeer@**bokxing.nl <roel.vanmeer at bokxing.nl>>
>>
>>
>>       Jakub Sobczak writes:
>>         I have never setup a live openSwan VPN tunnel, so please be
>>  understanding =)
>>      I received the following config details to establish connection to
>>    the other
>>      company's gateway:
>>           Key Exchange Encryption:        AES256  Data integrity: SHA1
>>      IKE SA renegotiation:   8 hrs                   Aggresive mode: No
>>      Use DH group:   1536 (group 5)
>>      Authentication: PSK
>>           IKE phase 2
>>      Data Encryption:        AES256  Data integrity: SHA1
>>      IPSec SA renegotiation: 1 hr    Aggresive mode: No
>>      Perfect forward secrecy:        Yes
>>      Use DH group (Perfect forward secrecy) :        1536 (group 5)
>>                This is my config from ipsec.conf (below). Apart from
>> that, I also      have
>>      ipsec.secret with the following content: left_IP(mine)
>>      right_IP(othercompany) "PSK"
>>       Just to be sure, the format of this needs to be:
>>    1.2.3.4 <URL:http://5.6.7.8>5.6.7.8: PSK "sharedkey"
>>               config setup
>>              nat_traversal=yes
>>                   virtual_private=%v4:<URL:http:**
>> //10.0.0.0/8,%v4:192.168.0.0/**16,%v4:172.      16.0.0/12>
>> 10.0.0.0/8,%v4:192.**168.0.0/16,%v4:172.16.0.0/12
>>
>>              oe=off
>>              protostack=klips
>>      conn abc
>>              #General
>>              keyingtries=1
>>              auto=add
>>       If you specify "auto=add" the other end will have to initiate the
>>  connection. Can you post the logs that show what happens during this
>>  time?
>>                    #IKE Params
>>              authby=secret
>>              keyexchange=ike
>>       This parameter does not occur in my manpage. Which version of
>> openswan    are you using?
>>                       ikelifetime=8h
>>              ike=aes256-sha1-modp1536
>>              #IPSec Params
>>              type=tunnel
>>              auth=esp
>>              pfs=yes
>>              compress=no
>>              keylife=60m
>>              esp=aes256-sha1
>>              #pfsgroup=modp1536
>>              # Left security gateway, subnet behind it, nexthop toward
>>    right.
>>              left=my_IP
>>              leftsubnet=<URL:http://192.**168.5.1/32<http://192.168.5.1/32>
>> >192.168.5.1/32                      right=other_comp_IP
>>
>>                rightsubnet=some_subnet
>>       As far as I can see, this is all correct.
>>    A general remark: in my experience it is often easier to begin with
>>  less specific configuration, for example:
>>    ike=aes
>>    instead of
>>    ike=aes256-sha1-modp1536
>>               The second phase does not seem to be established. What is
>> wrong? I      believe
>>      something with pfsgroup? How to properly set DH group?
>>       Best regards,
>>       Roel
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20120829/e0c5d941/attachment-0001.html>


More information about the Users mailing list