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

Jakub Sobczak sopel1000 at gmail.com
Wed Aug 29 05:46:17 EDT 2012


Hi,

A good sign is that we have a connection and that seems to be working,
but... am I right that there is a routing problem preventing the tunnel to
work properly...?

I have a dedicated server with eth0 set *to my-gateway-ip. *There is also
another subinterface: eth0:1 with ip 192.168.5.1. There is a virtual
machine with 192.168.5.2 on this dedicated server which is supposed to be
contacting "*remote-ip-inside-vpn*". Do you think it might be somehow
related to the problem (output below)?

I cannot ping "*remote-ip-inside-vpn*".

 Aug 29 11:35:46 : "conn" #2075: sending encrypted notification
> INVALID_ID_INFORMATION to *remote-gateway-ip:500
> *Aug 29 11:35:47 : packet from *remote-gateway-ip:500*: received Vendor
> ID payload [Dead Peer Detection]
> Aug 29 11:35:47 : packet from *remote-gateway-ip:500*: ignoring unknown
> Vendor ID payload [xxx]
> Aug 29 11:35:47 : "conn" #2076: responding to Main Mode
> Aug 29 11:35:47 : "conn" #2076: transition from state STATE_MAIN_R0 to
> state STATE_MAIN_R1
> Aug 29 11:35:47 : "conn" #2076: STATE_MAIN_R1: sent MR1, expecting MI2
> Aug 29 11:35:47 : "conn" #2076: transition from state STATE_MAIN_R1 to
> state STATE_MAIN_R2
> Aug 29 11:35:47 : "conn" #2076: STATE_MAIN_R2: sent MR2, expecting MI3
> Aug 29 11:35:47 : "conn" #2076: ignoring informational payload, type
> IPSEC_INITIAL_CONTACT msgid=00000000
> Aug 29 11:35:47 : "conn" #2076: Main mode peer ID is ID_IPV4_ADDR: *
> 'remote-gateway-ip'
> *Aug 29 11:35:47 : "conn" #2076: transition from state STATE_MAIN_R2 to
> state STATE_MAIN_R3
> Aug 29 11:35:47 : "conn" #2076: STATE_MAIN_R3: sent MR3, ISAKMP SA
> established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha
> group=modp1536}
> Aug 29 11:35:48 : "conn" #2076: the peer proposed: 192.168.5.2/32:0/0 -> *
> remote-ip-inside-vpn*/32:0/0
> Aug 29 11:35:48 : "conn" #2076: cannot respond to IPsec SA request because
> no connection is known for 192.168.5.2/32===my-gateway-ip<
> my-gateway-ip >[+S=C]...remote-gateway-ip<remote-gateway-ip>[+S=C]===*
> remote-ip-inside-vpn*/32


Regards,
Jakub



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

> Jakub Sobczak writes:
>
>  Each time I changed something I did:
>>
>>    ipsec auto --delete conn
>>    ipsec auto --add conn
>>    ipsec auto --up conn
>>
>
> This reloads the connection config, but not the shared secrets.
>
>
>  But it seems that it has failed to work. After this command:
>>
>>    ipsec auto --rereadsecrets
>>
>> I think it has negotiated the first phase, but there seems to be a
>> problem with the second phase.
>>
>
> Do you have any logs of openswan? E.g. the output of:
>
>
> ipsec auto --delete conn
> ipsec auto --add conn
> ipsec auto --up conn
>
> or recent content of the log file you posted before..
>
> Regards,
>
> Roel
>
>
>>
>>
>>    11:01:19.533205 IP remote-ip > my-ip.500: isakmp: phase 1 I ident
>>    11:01:19.533365 IP my-ip.500 > remote-ip: isakmp: phase 1 R ident
>>    11:01:20.127518 IP remote-ip > my-ip.500: isakmp: phase 1 I ident
>>    11:01:20.128536 IP my-ip.500 > remote-ip: isakmp: phase 1 R ident
>>    11:01:20.210036 IP remote-ip > my-ip.500: isakmp: phase 1 I ident[E]
>>    11:01:20.210213 IP my-ip.500 > remote-ip: isakmp: phase 1 R ident[E]
>>    11:01:20.303975 IP remote-ip > my-ip.500: isakmp: phase 2/others I
>>  oakley-quick[E]
>>    11:01:20.304176 IP my-ip.500 > remote-ip: isakmp: phase 2/others R
>>  inf[E]
>>
>>
>>
>> Thanks for the info about UDP port, I was expecting it to rather look
>> like this: <URL:http://1.2.3.4:500>1.2.3.**4:500 <http://1.2.3.4:500>and not separated wit the dot (.).
>>
>>
>> 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:
>>         tcpdump shows:
>>              10:37:<URL:tel:17.007960>17.007960 IP remote-ip.500 >
>> my-ip.500 :      isakmp: phase 1 I ident
>>         10:37:<URL:tel:17.008104>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:
>>    <URL:tel:1.2.3.4.500>1.2.3.4.500, but anyway it seems fine. What
>>  worries me however is:
>>
>>       .500 is the udp port that is used for setting up the connection.
>>                  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         [**
>> 699369228741c6d4ca094c93e242c9**de19e7b7c60000000500000500]
>>         003 "conn" #1806: Can't authenticate: no preshared key found for
>>         `my-ip' and `remote-ip'.  Attribute OAKLEY_AUTHENTICATION_METHOD
>>       Ok, you do receive traffic from the remote, so the firewall is not
>> the    problem. It can't find a secret for your configured connection,
>> however.
>>    Openswan does not pick up changes in your secrets file automatically.
>>    Have you restarted openswan since you put the secret in ipsec.secrets?
>>    You can also run
>>    ipsec auto --rereadsecrets
>>    to make sure Openswan picks up any changes there.
>>       Regards,
>>       Roel
>>                  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      <<URL:mailto:
>> <URL:mailto:roel.**vanmeer at bokxing.nl <roel.vanmeer at bokxing.nl>>roel.**
>> vanmeer at bokxing.      nl><URL:mailto:roel.vanmeer@**bokxing.nl<roel.vanmeer at bokxing.nl>
>> >roel.vanmeer@**bokxing.nl <roel.vanmeer at bokxing.nl>>
>>              Jakub Sobczak writes:
>>              Yes, the shared key line is formatted in the following way:
>>                1.2.3.4 <URL:<URL:<URL:http:/**/5.6.7.8/ <http://5.6.7.8/>
>> >http://5.6.7.8/><**URL:http://5.      6.7.8/>http://5.6.7.8/><URL:<**
>> URL:http://5.6.7.8>http://5.6.**7.8 <http://5.6.7.8>>           <URL:
>> http://5.6.7.8>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:
>> <URL:mailto:<**URL:mailto:roel.vanmeer@**bokxing.nl<roel.vanmeer at bokxing.nl>>roel.van
>>      meer at bokxing.nl>roel.vanmeer@**bokxing.           nl><URL:mailto:
>> <URL:mailto:ro**el.vanmeer at bokxing.nl <roel.vanmeer at bokxing.nl>>roel.**
>> vanmeer at bokxi      ng.nl><URL:mailto:roel.**vanmeer at bokxing.nl<roel.vanmeer at bokxing.nl>
>> >roel.**vanmeer at 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:<URL:<URL:http://5.6.7.8**>
>> http://5.6.7.8><URL:http://5.**6.7.8 <http://5.6.7.8>>http      ://
>> 5.6.7.8><URL:<URL:http://5.**6.7.8 <http://5.6.7.8>>http://5.6.7.8><URL:
>> http**://5.6.7.8 <http://5.6.7.8>      >5.6.7.8:      PSK "sharedkey"
>>                         config setup
>>                        nat_traversal=yes
>>                                       virtual_private=%v4:<URL:<**
>> URL:<URL:http://10.0.0.0/8,%**v4:192.168.0.0      /16,%v>
>> http://10.0.0.0/8,%v4:**192.168.0.0/16,%v           4:172><URL:
>> http://10.0.0.0/8,**%v4:192.168.0.0/16,%v4:172>htt**p://10.0.0<http://10.0.0>     .0/8,%v4:
>> 192.168.0.0/16,%v4:**172.                16.0.0/12><URL:<URL:http://**
>> 10.0.0.0/8,%v4:192.168.0.0/16,**%v4:172.16.      0.0/12>
>> http://10.0.0.0/8,%v4:**192.168.0.0/16,%v4:172.16.0.0/**12
>>   ><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:<URL:<URL:htt**
>> p://192.168.5.1/32 <http://192.168.5.1/32>>http://192.**168.5.1/32<http://192.168.5.1/32>     ><URL:
>> http://192.168.5.1/32>ht**tp://192.168.5.1/32 <http://192.168.5.1/32>><URL:
>>           <URL:http://192.168.5.1/32>ht**tp://192.168.5.1/32<http://192.168.5.1/32>
>> ><URL:http:**//192.168 <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/b4942bed/attachment-0001.html>


More information about the Users mailing list