[Openswan Users] Site-to-site VPN with openswan
Roel van Meer
roel.vanmeer at bokxing.nl
Wed Aug 29 05:53:50 EDT 2012
Jakub Sobczak writes:
> A good sign is that we have a connection and that seems to be working,
No, not yet. The logs say:
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<
So the peer has configured connection from
remote-ip-inside-vpn/32 to 192.168.5.2/32
but your configuration has
some_subnet to 192.168.5.1/32
You have to make sure these match exactly before the tunnel will be
established.
> but... am I right that there is a routing problem preventing the tunnel to
> work properly...?
No, your tunnel definition is not correct.
> 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".
You probably will only be able to ping the remote from your virtual machine,
because 192.168.5.1 is not included in the network range of the tunnel
(unless you do some trickery with iptables).
Regards,
Roel
>
>
>
> 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:
> <URL:http://192.168.5.2/32:0/0>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
> <URL:http://192.168.5.2/32===my-gateway-ip>192.168.5.2/32===my-gateway-i
> p<
> my-gateway-ip >[+S=C]...remote-gateway-ip<remote-gateway-ip>[+S=C]===rem
> ote-ip-inside-vpn/32
>
>
>
>
> Regards,
> Jakub
>
>
>
> 2012/8/29 Roel van Meer
> <<URL:mailto:roel.vanmeer at bokxing.nl>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:<URL:http://1.2.3.4:500>http://1.2.3.4:500><URL:http://1.2.3.4:50
> 0>1.2.3.4:500 and not separated wit the dot (.).
>
>
> 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:
> tcpdump shows:
>
> 10:37:<URL:tel:<URL:tel:17.007960>17.007960><URL:tel:17.007960>17.007
> 960 IP remote-ip.500 > my-ip.500 : isakmp: phase 1 I ident
>
> 10:37:<URL:tel:<URL:tel:17.008104>17.008104><URL:tel:17.008104>17.008
> 104 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:<URL:tel:1.2.3.4.500>1.2.3.4.500><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:<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:
> Yes, the shared key line is formatted in the following
> way:
> 1.2.3.4 <URL:<URL:<URL:<URL:http://5.6.7.8/>http://5.6.7.8/><URL:htt
> p://5.6.7.8/>http://5.6.7.8/><URL:<URL:http://5>http://5.
> 6.7.8/><URL:http://5.6.7.8/>http://5.6.7.8/><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:<URL:mailto:roel.vanmeer at bokxin
> g.nl>roel.vanmeer at bokxing.nl>roel.van
> <URL:mailto:meer at bokxing.nl>meer at bokxing.nl>roel.vanmeer at bokxing.
>
> nl><URL:mailto:<URL:mailto:<URL:mailto:roel.vanmeer at bokxing.nl>roel.
> vanmeer at bokxing.nl>roel.vanmeer at bokxi
> <URL:http://ng.nl>ng.nl><URL:mailto:<URL:mailto:roel.vanmeer at bokxing.
> nl>roel.vanmeer at bokxing.nl><URL:mailto:roel.vanmeer at bokxing.nl>roel.va
> nmeer 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:<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>http
> ://<URL:http://5.6.7.8>5.6.7.8><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>htt
> p://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:<URL:http://10.0.0.0/8,%v4:192.1
> 68.0.0>http://10.0.0.0/8,%v4:192.168.0.0
> /16,%v><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:<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><URL:http://10.0.0>http://10.0.0
>
> .0/8,%v4:<URL:http://192.168.0.0/16,%v4:172>192.168.0.0/16,%v4:172.
>
> 16.0.0/12><URL:<URL:<URL:http://10.0.0.0/8,%v4:192.168.0.0/16,%v4:1
> 72.16>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>ht
> tp://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>ht
> tp://10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12>10.0.0.0
> /8,%v4:<URL:http://192.168.0.0/16,%v4:172.16.0.0/12>192.168.0.0/16,%v
> 4: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:<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://19
> 2.168.5.1/32>http://192.168.5.1/32><URL:
> <URL:<URL:http://192.168.5.1/32>http://192.168.5.1/32><URL:http://19
> 2.168.5.1/32>http://192.168.5.1/32><URL:<URL:http://192.168>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