[Openswan Users] Site-to-site VPN with openswan
Jakub Sobczak
sopel1000 at gmail.com
Wed Aug 29 05:08:28 EDT 2012
Each time I changed something I did:
ipsec auto --delete conn
> ipsec auto --add conn
> ipsec auto --up conn
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.
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: 1.2.3.4:500 and not separated wit the dot (.).
Regards,
Jakub
2012/8/29 Roel van Meer <roel.vanmeer at bokxing.nl>
> Jakub Sobczak writes:
>
> 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:
>>
>
> .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: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: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" .
>> 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: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:
>> 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: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 <http://5.6.7.8>: PSK "sharedkey"
>> config setup
>> nat_traversal=yes
>> virtual_private=%v4:<URL:<**URL:
>> http://10.0.0.0/8,%v4:192.**168.0.0/16,%v 4:172>
>> 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:http://**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>192.168.**5.1/32 <http://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/ae0c0847/attachment-0001.html>
More information about the Users
mailing list