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

Wed Jul 16 04:03:15 EDT 2014

Iptables and xfrm policy in attachment.
10.0.100.1 is attacheted to lo:1 interface, not to eth0. The goal is to access ldap server behind Cisco. If it can be achieved without fake LAN on openswan side than I can live with it. 500/udp on eth0 is open (see iptables, it has ACCEPT rule for INPUT chain). What do you mean by setting GW for lo:1 interface?

Regards
Piotr

Dnia 2014-07-16, śro o godzinie 08:44 +0100, Nick Howitt pisze:
Thinking about it, the problem could be that your virtual interface, 10.0.100.1, is connected to your external interface. Apart from defining a gateway for it, I have no idea what to do about it.

On 16/07/2014 08:03, Nick Howitt wrote:

Sorry but I am not particularly familiar with the iptables-save format. Can you please give the output to:
iptables -nvL
iptables -nvL -t nat

Please also use my POSTROUTING rule as it is more generic.

As a question, why is Openswan nat'd? If it has a public IP address con you not open port UDP:500 in the INPUT chain and restart the conn?

I agree the routing looks odd. You could try overriding it, but normally routing is controlled through "ip xfrm". Try dumping "ip xfrm policy"

I agree the tunnel appears to be up from your log.

Beyond this I may not be much more help.

Nick

On 16/07/2014 07:34, Piotr Pawłowski wrote:

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

_______________________________________________
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/20140716/f80c78fe/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xfrm_policy
URL: <http://lists.openswan.org/pipermail/users/attachments/20140716/f80c78fe/attachment-0002.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: iptables
URL: <http://lists.openswan.org/pipermail/users/attachments/20140716/f80c78fe/attachment-0003.ksh>