[Openswan Users] Ipsec vpn host-to-host between openswan and Cisco device

Piotr Pawłowski piotr.pawlowski at goyello.com
Tue Jul 15 03:51:32 EDT 2014 

On Cisco side there is 10.0.0.0/24 network while openswan runs on one server where address 10.0.100.1 is a IP attached to loopback sub-interface.


Dnia 2014-07-14, pon o godzinie 15:32 +0100, Nick Howitt pisze:


What are the real LAN subnets at either end of the tunnel?

On 2014-07-14 13:51, Piotr Pawłowski wrote:
> Indeed... Typo in networks (facepalm)... That's the result of debugging
> too long. Thanks for the tip.
> Now VPN is established, however there is no possibility to reach any
> end
> (from openswan I am not able to reach 10.0.0.2/32 and from Cisco I
> cannot reach 10.0.100.1).
> Route on openswan side is added by the software. Route on Cisco side
> looks like this:
> ip route 10.0.100.1 255.255.255.255 $ciscoPublicIP
>
> Any kind of tip will be helpful.
>
> Regards
> Piotr
>
>
> Dnia 2014-07-14, pon o godzinie 09:02 +0100, Nick Howitt pisze:
>> I don't know if your configs are edited, but you must not have any
>> blank
>> lines in a conn. A blank line signifies the end of a conn. It probably
>> also applies to config setup. If you want, you can use an indented #
>> rather than a totally blank line.
>>
>> I can't read Cisco configs but it also seems that your
>> left/rightsubnets
>> don't match your access-list. Is this correct or do you specify
>> subnets
>> elsewhere in the Cisco config?
>>
>> Nick
>>
>> On 2014-07-14 08:36, Piotr Pawłowski wrote:
>> > Dear all,
>> >
>> > From two weeks I am trying to setup ipsec vpn connection between two
>> > hosts. One of them is openswan on linux, other is Cisco device. Without
>> > luck.
>> > Openswan configuration below:
>> >
>> > config setup
>> >         interfaces=%defaultroute
>> >         plutodebug=none
>> >         klipsdebug=none
>> >         plutoopts="--perpeerlog"
>> >
>> >         nat_traversal=yes
>> >         virtual_private=%v4:10.0.100.1/32,%v4:10.0.0.2/32
>> >         oe=off
>> >         protostack=netkey
>> >         plutostderrlog=/var/log/pluto.log
>> > conn testConnection
>> >         auto=start
>> >         type=tunnel
>> >         aggrmode=no
>> >
>> >         left=$openswanPublicIP
>> >         leftsubnet=10.0.100.1/32
>> >         leftsourceip=10.0.100.1
>> >
>> >         right=$ciscoPublicIP
>> >         rightsubnet=10.0.0.2/32
>> >
>> >         keyexchange=ike
>> >         ike=3des-md5-modp1024
>> >
>> >         authby=secret
>> >
>> >         phase2=esp
>> >         phase2alg=3des-md5
>> >         pfs=yes
>> >
>> >
>> > Cisco configuration:
>> >
>> > crypto isakmp policy 1
>> >  encr 3des
>> >  hash md5
>> >  authentication pre-share
>> >  group 2
>> >  lifetime 28800
>> > crypto isakmp key TestKey address $openswanPublicIP
>> > crypto ipsec transform-set OPENSWAN esp-3des esp-md5-hmac
>> >  mode tunnel
>> > crypto map openswan-map 1 ipsec-isakmp
>> >  set peer $openswanPublicIP
>> >  set transform-set OPENSWAN
>> >  match address 190
>> > access-list 190 permit ip 10.0.0.0 0.0.1.255 10.0.100.0 0.0.0.255
>> >
>> >
>> >
>> > IMHO everything looks fine. Openswan thinks different. Below output
>> > from
>> > pluto.log.
>> >
>> > Plutorun started on Mon Jul 14 07:01:57 UTC 2014
>> > adjusting ipsec.d to /etc/ipsec.d
>> > Starting Pluto (Openswan Version 2.6.28; Vendor ID OEQ{O\177nez{CQ)
>> > pid:23920
>> > SAref support [disabled]: Protocol not available
>> > SAbind support [disabled]: Protocol not available
>> > Setting NAT-Traversal port-4500 floating to on
>> >    port floating activation criteria nat_t=1/port_float=1
>> >    NAT-Traversal support  [enabled]
>> > using /dev/urandom as source of random entropy
>> > ike_alg_register_enc(): Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
>> > ike_alg_register_enc(): Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
>> > ike_alg_register_enc(): Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
>> > ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
>> > ike_alg_register_enc(): Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
>> > ike_alg_register_hash(): Activating OAKLEY_SHA2_512: Ok (ret=0)
>> > ike_alg_register_hash(): Activating OAKLEY_SHA2_256: Ok (ret=0)
>> > starting up 1 cryptographic helpers
>> > started helper pid=23924 (fd:4)
>> > Using Linux 2.6 IPsec interface code on 2.6.32-5-amd64 (experimental
>> > code)
>> > using /dev/urandom as source of random entropy
>> > ike_alg_register_enc(): Activating aes_ccm_8: Ok (ret=0)
>> > ike_alg_add(): ERROR: Algorithm already exists
>> > ike_alg_register_enc(): Activating aes_ccm_12: FAILED (ret=-17)
>> > ike_alg_add(): ERROR: Algorithm already exists
>> > ike_alg_register_enc(): Activating aes_ccm_16: FAILED (ret=-17)
>> > ike_alg_add(): ERROR: Algorithm already exists
>> > ike_alg_register_enc(): Activating aes_gcm_8: FAILED (ret=-17)
>> > ike_alg_add(): ERROR: Algorithm already exists
>> > ike_alg_register_enc(): Activating aes_gcm_12: FAILED (ret=-17)
>> > ike_alg_add(): ERROR: Algorithm already exists
>> > ike_alg_register_enc(): Activating aes_gcm_16: FAILED (ret=-17)
>> > Changed path to directory '/etc/ipsec.d/cacerts'
>> > Changed path to directory '/etc/ipsec.d/aacerts'
>> > Changed path to directory '/etc/ipsec.d/ocspcerts'
>> > Changing to directory '/etc/ipsec.d/crls'
>> >   Warning: empty directory
>> > added connection description "testConnection"
>> > listening for IKE messages
>> > NAT-Traversal: Trying new style NAT-T
>> > NAT-Traversal: ESPINUDP(1) setup failed for new style NAT-T family IPv4
>> > (errno=19)
>> > NAT-Traversal: Trying old style NAT-T
>> > adding interface eth0/eth0 $openswanPublicIP:500
>> > adding interface eth0/eth0 $openswanPublicIP:4500
>> > adding interface lo:1/lo:1 10.0.100.1:500
>> > adding interface lo:1/lo:1 10.0.100.1:4500
>> > adding interface lo/lo 127.0.0.1:500
>> > adding interface lo/lo 127.0.0.1:4500
>> > adding interface lo/lo ::1:500
>> > loading secrets from "/etc/ipsec.secrets"
>> > loading secrets from "/var/lib/openswan/ipsec.secrets.inc"
>> > "testConnection" #1: initiating Main Mode
>> > "testConnection" #1: received Vendor ID payload [RFC 3947] method set
>> > to=109
>> > "testConnection" #1: enabling possible NAT-traversal with method 4
>> > "testConnection" #1: transition from state STATE_MAIN_I1 to state
>> > STATE_MAIN_I2
>> > "testConnection" #1: STATE_MAIN_I2: sent MI2, expecting MR2
>> > "testConnection" #1: received Vendor ID payload [Cisco-Unity]
>> > "testConnection" #1: received Vendor ID payload [Dead Peer Detection]
>> > "testConnection" #1: ignoring unknown Vendor ID payload
>> > [9df211f6d27b7ea9251edca1d227fdd5]
>> > "testConnection" #1: received Vendor ID payload [XAUTH]
>> > "testConnection" #1: NAT-Traversal: Result using RFC 3947
>> > (NAT-Traversal): no NAT detected
>> > "testConnection" #1: transition from state STATE_MAIN_I2 to state
>> > STATE_MAIN_I3
>> > "testConnection" #1: STATE_MAIN_I3: sent MI3, expecting MR3
>> > "testConnection" #1: Main mode peer ID is ID_IPV4_ADDR:
>> > '$ciscoPublicIP'
>> > "testConnection" #1: transition from state STATE_MAIN_I3 to state
>> > STATE_MAIN_I4
>> > "testConnection" #1: STATE_MAIN_I4: ISAKMP SA established
>> > {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5
>> > group=modp1024}
>> > "testConnection" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP
>> > +IKEv2ALLOW {using isakmp#1 msgid:b73ac6a6
>> > proposal=3DES(3)_192-MD5(1)_128 pfsgroup=OAKLEY_GROUP_MODP1024}
>> > "testConnection" #1: ignoring informational payload, type
>> > NO_PROPOSAL_CHOSEN msgid=00000000
>> > "testConnection" #1: received and ignored informational message
>> > :testConnection" #2: max number of retransmissions (2) reached
>> > STATE_QUICK_I1.  No acceptable response to our first Quick Mode
>> > message:
>> > perhaps peer likes no proposal
>> >
>> > I also tried with 'transform-set esp-aes 256 esp-sha-hmac' on Cisco
>> > side
>> > and keyexchange=ike , ike=3des-md5-modp1024 , phase2=esp ,
>> > phase2alg=3des-md5;modp1024 on openswan side. Also with same error as
>> > shown in pluto.log .
>> >
>> > Can anybody point the area, where I am doing something wrong?
>> > Thank you in advance.
>> >
>> > Regards
>> > Piotr
>> > _______________________________________________
>> > Users at lists.openswan.org<mailto:Users at lists.openswan.org>
>> > https://lists.openswan.org/mailman/listinfo/users
>> > Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
>> > Building and Integrating Virtual Private Networks with Openswan:
>> > http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
> _______________________________________________
> Users at lists.openswan.org<mailto:Users at lists.openswan.org>
> https://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20140715/2d592d1b/attachment-0001.html>

More information about the Users mailing list