[Openswan Users] Site-to-site VPN with openswan
Roel van Meer
roel.vanmeer at bokxing.nl
Wed Aug 29 05:29:50 EDT 2012
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 and not separated wit the dot
> (.).
>
>
>
> Regards,
> Jakub
>
>
>
> 2012/8/29 Roel van Meer
> <<URL:mailto:roel.vanmeer at 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
> [699369228741c6d4ca094c93e242c9de19e7b7c60000000500000500]
> 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><URL:mailto:roel.vanmeer at 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/><URL:http://5.
> 6.7.8/>http://5.6.7.8/><URL:<URL: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 at bokxing.nl>roel.van
> meer at bokxing.nl>roel.vanmeer at bokxing.
> nl><URL:mailto:<URL:mailto:roel.vanmeer at bokxing.nl>roel.vanmeer at bokxi
> ng.nl><URL:mailto: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><URL:<URL:http://5.6.7.8>http://5.6.7.8><URL: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>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:http://192.168.5.1/32>http://192.168.5.1/32
> ><URL:http://192.168.5.1/32>http://192.168.5.1/32><URL:
> <URL:http://192.168.5.1/32>http://192.168.5.1/32><URL: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
>
>
More information about the Users
mailing list