<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Try something like:<br>
<br>
route add 10.0.0.0 mask 255.255.255.0 $openswanGW<br>
<br>
You may need to delete the original route first.<br>
<br>
If your linux uses /etc/sysconfig/networking-scripts/ifcfg files you
may be able to add GATEWAY = $openswanGW to the lo.1 file (or
whichever contains your interface definition) as an alternative to
adding a route. Then restart the interface.<br>
<div class="moz-cite-prefix"><br>
Beyond this I am stuck.<br>
<br>
On 16/07/2014 09:03, Piotr Pawłowski wrote:<br>
</div>
<blockquote
cite="mid:1405497792.20418.14.camel@GY-GD-K059.goyello.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="GENERATOR" content="GtkHTML/4.6.6">
Iptables and xfrm policy in attachment.<br>
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?<br>
<br>
Regards<br>
Piotr<br>
<br>
<br>
Dnia 2014-07-16, śro o godzinie 08:44 +0100, Nick Howitt pisze:<br>
<blockquote type="CITE">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.<br>
<br>
</blockquote>
<blockquote type="CITE">On 16/07/2014 08:03, Nick Howitt wrote:<br>
<br>
</blockquote>
<blockquote type="CITE">
<blockquote type="CITE">Sorry but I am not particularly familiar
with the iptables-save format. Can you please give the output
to:<br>
iptables -nvL<br>
iptables -nvL -t nat<br>
<br>
Please also use my POSTROUTING rule as it is more generic.<br>
<br>
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?<br>
<br>
I agree the routing looks odd. You could try overriding it,
but normally routing is controlled through "ip xfrm". Try
dumping "ip xfrm policy"<br>
<br>
I agree the tunnel appears to be up from your log.<br>
<br>
Beyond this I may not be much more help.<br>
<br>
Nick<br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote type="CITE">On 16/07/2014 07:34, Piotr Pawłowski
wrote:<br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">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:<br>
<br>
Destination Gateway Genmask Flags Metric
Ref Use Iface<br>
10.0.0.0 0.0.0.0 255.255.255.0 U 0
0 0 eth0<br>
$openswanNetwork 0.0.0.0 255.255.255.0 U
0 0 0 eth0<br>
0.0.0.0 $openswanGW 0.0.0.0 UG 0
0 0 eth0<br>
<br>
Regards<br>
Piotr<br>
<br>
Dnia 2014-07-15, wto o godzinie 17:44 +0100, Nick Howitt
pisze:<br>
<blockquote type="CITE">I am not sure about your first INPUT
rule and would normally use:<br>
<br>
iptables -A INPUT -p 50 -j ACCEPT<br>
<br>
which could be refined with a "-s $ciscoPublicIP". Your
POSTROUTING rule should be fine instead of mine.<br>
<br>
Can you post your connection log, your conn as it is now
and a traceroute to the Cisco router.<br>
<br>
Nick<br>
<br>
On 15/07/2014 13:36, Piotr Pawłowski wrote:<br>
<br>
<blockquote type="CITE">
<pre>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:
</pre>
<blockquote type="CITE">
<pre>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:
</pre>
<blockquote type="CITE">
<pre>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:
</pre>
<blockquote type="CITE">
<pre>What are the real LAN subnets at either end of the tunnel?
On 2014-07-14 13:51, Piotr Pawłowski wrote:
</pre>
<blockquote type="CITE">
<pre>Indeed... Typo in networks (facepalm)... That's the result of
</pre>
</blockquote>
<pre>debugging
</pre>
<blockquote type="CITE">
<pre>too long. Thanks for the tip.
Now VPN is established, however there is no possibility to reach
</pre>
</blockquote>
<pre>any
</pre>
<blockquote type="CITE">
<pre>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
</pre>
</blockquote>
<pre>side
</pre>
<blockquote type="CITE">
<pre>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:
</pre>
<blockquote type="CITE">
<pre>I don't know if your configs are edited, but you must not have
</pre>
</blockquote>
</blockquote>
<pre>any
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<pre>blank
lines in a conn. A blank line signifies the end of a conn. It
</pre>
</blockquote>
</blockquote>
<pre>probably
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<pre>also applies to config setup. If you want, you can use an
</pre>
</blockquote>
</blockquote>
<pre>indented #
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<pre>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:
</pre>
<blockquote type="CITE">
<pre>Dear all,
>From two weeks I am trying to setup ipsec vpn connection
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>between two
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>hosts. One of them is openswan on linux, other is Cisco device.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>Without
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>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
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>0.0.0.255
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>IMHO everything looks fine. Openswan thinks different. Below
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>output
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>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
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>OEQ{O177nez{CQ)
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>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
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>(ret=0)
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>ike_alg_register_enc(): Activating OAKLEY_TWOFISH_CBC: Ok
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>(ret=0)
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>ike_alg_register_enc(): Activating OAKLEY_SERPENT_CBC: Ok
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>(ret=0)
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
ike_alg_register_enc(): Activating OAKLEY_BLOWFISH_CBC: Ok
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>(ret=0)
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>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
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>(experimental
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>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
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>family IPv4
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>(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]
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>method set
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>to=109
"testConnection" #1: enabling possible NAT-traversal with
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>method 4
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>"testConnection" #1: transition from state STATE_MAIN_I1 to
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>state
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>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
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>Detection]
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>"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
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>state
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>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
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>state
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>STATE_MAIN_I4
"testConnection" #1: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>prf=oakley_md5
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>group=modp1024}
"testConnection" #2: initiating Quick Mode
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>PSK+ENCRYPT+TUNNEL+PFS+UP
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>+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
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>Cisco
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>side
and keyexchange=ike , ike=3des-md5-modp1024 , phase2=esp ,
phase2alg=3des-md5;modp1024 on openswan side. Also with same
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>error as
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>shown in pluto.log .
Can anybody point the area, where I am doing something wrong?
Thank you in advance.
Regards
Piotr
_______________________________________________
<a moz-do-not-send="true" href="mailto:Users@lists.openswan.org">Users@lists.openswan.org</a>
<a moz-do-not-send="true" href="https://lists.openswan.org/mailman/listinfo/users">https://lists.openswan.org/mailman/listinfo/users</a> [1]
Micropayments:
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre><a moz-do-not-send="true" href="https://flattr.com/thing/38387/IPsec-for-Linux-made-easy">https://flattr.com/thing/38387/IPsec-for-Linux-made-easy</a> [2]
</pre>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
<pre>Building and Integrating Virtual Private Networks with
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>Openswan:
</pre>
</blockquote>
<pre><a moz-do-not-send="true" href="http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155">http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155</a>
</pre>
<blockquote type="CITE">
<pre>[3]
</pre>
<blockquote type="CITE">
<pre>_______________________________________________
<a moz-do-not-send="true" href="mailto:Users@lists.openswan.org">Users@lists.openswan.org</a>
<a moz-do-not-send="true" href="https://lists.openswan.org/mailman/listinfo/users">https://lists.openswan.org/mailman/listinfo/users</a> [1]
Micropayments:
</pre>
</blockquote>
<pre><a moz-do-not-send="true" href="https://flattr.com/thing/38387/IPsec-for-Linux-made-easy">https://flattr.com/thing/38387/IPsec-for-Linux-made-easy</a> [2]
</pre>
<blockquote type="CITE">
<pre>Building and Integrating Virtual Private Networks with Openswan:
</pre>
</blockquote>
</blockquote>
<pre><a moz-do-not-send="true" href="http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155">http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155</a>
</pre>
<blockquote type="CITE">
<pre>[3]
</pre>
</blockquote>
<pre>Links:
------
[1] <a moz-do-not-send="true" href="https://lists.openswan.org/mailman/listinfo/users">https://lists.openswan.org/mailman/listinfo/users</a>
[2] <a moz-do-not-send="true" href="https://flattr.com/thing/38387/IPsec-for-Linux-made-easy">https://flattr.com/thing/38387/IPsec-for-Linux-made-easy</a>
[3]
<a moz-do-not-send="true" href="http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155">http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
<br>
<br>
<pre>_______________________________________________
<a moz-do-not-send="true" href="mailto:Users@lists.openswan.org">Users@lists.openswan.org</a>
<a moz-do-not-send="true" href="https://lists.openswan.org/mailman/listinfo/users">https://lists.openswan.org/mailman/listinfo/users</a>
Micropayments: <a moz-do-not-send="true" href="https://flattr.com/thing/38387/IPsec-for-Linux-made-easy">https://flattr.com/thing/38387/IPsec-for-Linux-made-easy</a>
Building and Integrating Virtual Private Networks with Openswan:
<a moz-do-not-send="true" href="http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155">http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155</a>
</pre>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>