<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>