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

Piotr Pawłowski piotr.pawlowski at goyello.com
Wed Jul 16 02:34:32 EDT 2014


pluto.log in attachment as well as current iptables rules. traceroute fails on first hoop - it looks like it even doesn't know which path use for 10.0.0.0/24 network. Routing table:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
$openswanNetwork     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         $openswanGW     0.0.0.0         UG    0      0        0 eth0

Regards
Piotr

Dnia 2014-07-15, wto o godzinie 17:44 +0100, Nick Howitt pisze:
I am not sure about your first INPUT rule and would normally use:

iptables -A INPUT -p 50 -j ACCEPT

which could be refined with a "-s $ciscoPublicIP". Your POSTROUTING rule should be fine instead of mine.

Can you post your connection log, your conn as it is now and a traceroute to the Cisco router.

Nick

On 15/07/2014 13:36, Piotr Pawłowski wrote:



I'va cleared iptables and added your rule - still nothing. Before change
I had only this:
iptables -A POSTROUTING -t nat -d 10.0.0.0/24 -o eth0 -m policy --dir
out --pol ipsec -j ACCEPT
iptables -A INPUT -m policy --dir in --pol ipsec -j ACCEPT
iptables -A INPUT -p udp -m multiports --dports 500,4500 -j ACCEPT
iptables -A FORWARD -m policy --dir in --pol ipsec -j ACCEPT
Default chains policy is to accept everything.

Any other ideas?
Thanks in advance.

Piotr

Dnia 2014-07-15, wto o godzinie 12:53 +0100, Nick Howitt pisze:



What firewall rules do you have in place - especially in the POSTROUTING
chain which might affect this? If you have nothing, try adding this
generic one:

iptables -t nat -I POSTROUTING -m policy --dir out --pol ipsec -j ACCEPT

On 2014-07-15 10:44, Piotr Pawłowski wrote:



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{O177nez{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 [1]
Micropayments:



https://flattr.com/thing/38387/IPsec-for-Linux-made-easy [2]



Building and Integrating Virtual Private Networks with



Openswan:



http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155



[3]



_______________________________________________
Users at lists.openswan.org<mailto:Users at lists.openswan.org>
https://lists.openswan.org/mailman/listinfo/users [1]
Micropayments:



https://flattr.com/thing/38387/IPsec-for-Linux-made-easy [2]



Building and Integrating Virtual Private Networks with Openswan:




http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155



[3]




Links:
------
[1] https://lists.openswan.org/mailman/listinfo/users
[2] https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
[3]
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/20140716/32b49073/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pluto.log
Type: text/x-log
Size: 4674 bytes
Desc: pluto.log
URL: <http://lists.openswan.org/pipermail/users/attachments/20140716/32b49073/attachment-0001.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: iptables
URL: <http://lists.openswan.org/pipermail/users/attachments/20140716/32b49073/attachment-0001.ksh>


More information about the Users mailing list