[Openswan Users] Site-to-site VPN with openswan
Jakub Sobczak
sopel1000 at gmail.com
Wed Aug 29 12:18:24 EDT 2012
Roel,
Willie,
you are my heros =), the tunnel has been established! It's ubelievable that
in fact all that was wrong was stupid IP mistake and command to
"rereadkeys".
104 "conn" #2795: STATE_MAIN_I1: initiate
> 003 "conn" #2795: received Vendor ID payload [Dead Peer Detection]
> 003 "conn" #2795: ignoring unknown Vendor ID payload []
> 106 "conn" #2795: STATE_MAIN_I2: sent MI2, expecting MR2
> 108 "conn" #2795: STATE_MAIN_I3: sent MI3, expecting MR3
> 004 "conn" #2795: STATE_MAIN_I4: ISAKMP SA established
> {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1536}
> 117 "conn" #2796: STATE_QUICK_I1: initiate
> 004 "conn" #2796: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
> mode {ESP=>0x5d04057f <0xc472b051 xfrm=AES_256-HMAC_SHA1 NATOA=none
> NATD=none DPD=none}
But there was still iptables problem (I guess) which I cannot set... I am
probably doing something wrong. I am trying to mess with DNAT and SNAT ->
the virtual machine on my side (which is supposed to be communicating with
the machine on the other side of the tunnel) has 192.168.56.111, but I told
the other party to set my side as 192.168.5.2.
So I did the following:
sudo iptables -t nat -I PREROUTING -d 192.168.5.2 -j DNAT --to-destination
192.168.56.111
sudo iptables -t nat -I POSTROUTING -s 192.168.56.111 -j SNAT --to
192.168.5.2
sudo iptables -I FORWARD -d 192.168.5.2 -j ACCEPT
sudo iptables -I FORWARD -d 192.168.56.111 -j ACCEPT
And... it seems to be working =) At least I can ping the IP which is inside
the VPN.
Thanks again!
Regards,
Jakub
2012/8/29 Roel van Meer <roel.vanmeer at bokxing.nl>
> 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 <http://192.168.5.2/32===my-gateway-ip>>192.168.5.2/32==**
>> =my-gateway-i <http://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@**bokxing.nl<roel.vanmeer at bokxing.nl>
>> >roel.vanmeer@**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>h**
>> ttp://1.2.3.4:500 <http://1.2.3.4:500>><URL:http://**1.2.3.4:50<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>>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:
>> 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
>> [**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:<**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:
>> 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/>>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/>h**ttp://5.6.7.8/ <http://5.6.7.8/>
>> ><URL:<URL:<URL:**http://5.6 <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>htt**p://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:<**URL:mailto:<URL:mailto:roel.**
>> vanmeer at bokxin <roel.vanmeer at bokxin> g.nl>roel.vanmeer at bokxing.nl>**roel.van
>> <URL:mailto:meer at bokxing.nl>m**eer at bokxing.nl <meer at bokxing.nl>
>> >roel.vanmeer@**bokxing. nl><URL:mailto:<URL:mailto:<
>> **URL:mailto:roel.vanmeer@**bokxing.nl <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<roel.vanmeer at bokxing>.
>> nl>roel.vanmeer at bokxing.nl><**URL:mailto:roel.vanmeer@**bokxing.nl<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>>http://5.6.7.8><URL:ht**tp://5.6.7<http://5.6.7>.
>> 8>http://5.6.7.8><URL:<URL:htt**p://5.6.7.8 <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>>http://5
>> .6.7.8><URL:http://5.6.7.8>htt**p://5.6.7.8 <http://5.6.7.8>><URL:<URL:
>> http://**5.6.7.8 <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<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>htt**
>> p://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:ht**tp://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 <http://192.168>.
>> 5.1/32><URL:http://192.168.5.**1/32 <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>
>> >http://192.168.5.1/32><**URL:http://19 2.168.5.1/32>
>> http://192.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>>
>> http://192.168.5.1/32><**URL:http://19 2.168.5.1/32>
>> http://192.168.5.**1/32 <http://192.168.5.1/32>><URL:<URL:http://192.168>
>> **http://192 <http://192> .168. 5.1/32><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/77b9b767/attachment-0001.html>
More information about the Users
mailing list