<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-15"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#333399">
<font size="-1">Hi Andy,<br>
<br>
Yes, IP forwarding is on - this is our main gateway.<br>
<br>
If I do ping -I &lt;local&gt; &lt;remote&gt; from the gateway machine,
then this works fine. However, if I do the same thing from a PC behind
the gateway (and in the private vpn network) then this doesn't work<br>
<br>
The packets aren't being dropped by our firewall, so it looks like
they're just being swallowed up by the vpn...weird.<br>
<br>
Matt<br>
<br>
<br>
</font>on 04/08/2006 16:16 Andy Gay said the following:
<blockquote cite="mid1154704607.5592.99.camel@tahini.andynet.net"
 type="cite">
  <pre wrap="">On Fri, 2006-08-04 at 15:48 +0100, Matthew Claridge wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">nope, didn't want to turn it off just yet, not until it works :-)

OK, it looks like my problem is that I know nothing about netkey -
I've always had ipsec0 interfaces in the past...

The other problem is that I can't connect to anything on the other
side of the tunnel....but if this all looks ok, then maybe the problem
is elsewhere....
    </pre>
  </blockquote>
  <pre wrap=""><!---->
You have IP forwarding enabled, right?

Make sure any packets you send match the tunnel policy. The source
address must be in the leftsubnet. If you're connecting from the
Openswan system itself, you'll need to do something to explicitly force
that - e.g. with ping you can do ping -I &lt;local address&gt; ...

Setting leftsourceip=&lt;local address&gt; is a good idea, it'll make all
locally generated packets take that source address if their destination
is in rightsubnet.
  </pre>
  <blockquote type="cite">
    <pre wrap="">cheers
Matt

on 04/08/2006 15:32 Andy Gay said the following: 
    </pre>
    <blockquote type="cite">
      <pre wrap="">On Fri, 2006-08-04 at 12:53 +0100, Matthew Claridge wrote:
  
      </pre>
      <blockquote type="cite">
        <pre wrap="">ok, I've got it logging, but then I get really strange results......

/var/log/secure shows:

Aug  4 12:47:24 vpn1 pluto[3116]: | inserting event EVENT_SA_REPLACE, 
timeout in 28084 seconds for #2
    
        </pre>
      </blockquote>
      <pre wrap="">Hmm. You don't want to turn off plutodebug, eh? :)

  
      </pre>
      <blockquote type="cite">
        <pre wrap="">Aug  4 12:47:24 vpn1 pluto[3116]: "amextunnel" #2: STATE_QUICK_I2: sent 
QI2, IPsec SA established {ESP=&gt;0x8db87503 &lt;0xf5b66251 
xfrm=3DES_0-HMAC_MD5 NATD=none DPD=none}
Aug  4 12:47:24 vpn1 pluto[3116]: | modecfg pull: noquirk policy:push 
not-client
Aug  4 12:47:24 vpn1 pluto[3116]: | phase 1 is done, looking for phase 1 
to unpend
Aug  4 12:47:24 vpn1 pluto[3116]: | next event EVENT_PENDING_PHASE2 in 
111 seconds

Now, to my understanding, "IPSec SA established" means it thinks its 
brought the tunnel up successfully.....the remote Cisco logs also show 
the tunnel being established
    
        </pre>
      </blockquote>
      <pre wrap="">Yup

  
      </pre>
      <blockquote type="cite">
        <pre wrap="">......however, /var/log/messages shows:

Aug  4 12:47:18 vpn1 ipsec__plutorun: 104 "amextunnel" #1: 
STATE_MAIN_I1: initiate
Aug  4 12:47:18 vpn1 ipsec__plutorun: ...could not start conn "amextunnel"

    
        </pre>
      </blockquote>
      <pre wrap="">That's normal - you always get those after restarting Openswan for conns
with auto=start. I've no idea why, but you can just ignore it.

  
      </pre>
      <blockquote type="cite">
        <pre wrap="">In addition to that, the route is being set up completely wrongly:

192.168.201.0   0.0.0.0         255.255.255.0   U         0 0          0 
eth0

    
        </pre>
      </blockquote>
      <pre wrap="">That's OK, if you're using netkey. BTW - use 'ip route' to look at your
routing table.

  
      </pre>
      <blockquote type="cite">
        <pre wrap="">Basically its setting up a route to the remote network, but through my 
default gateway, NOT through the ipsec interface, or even the ipsec IP 
address...

    
        </pre>
      </blockquote>
      <pre wrap="">Oh. Do you have an ipsec0 interface then? So you're using KLIPS?

  
      </pre>
      <blockquote type="cite">
        <pre wrap="">Anyone have any ideas whats going wrong?
    
        </pre>
      </blockquote>
      <pre wrap="">Actually, this all looks OK. What problem are you actually having?

  
      </pre>
      <blockquote type="cite">
        <pre wrap="">cheers
Matt


on 03/08/2006 15:18 Andy Gay said the following:

    
        </pre>
        <blockquote type="cite">
          <pre wrap="">On Thu, 2006-08-03 at 09:53 +0100, Matthew Claridge wrote:
 

      
          </pre>
          <blockquote type="cite">
            <pre wrap="">Hi,

I'm setting up a vpn tunnel to one of our customers' Cisco Pix 
firewalls, from a Fedora Core5 system, using OpenSwan-2.4.4-1.1.2.1

The tunnel is failing to start, but nothing useful is logged:
   

        
            </pre>
          </blockquote>
          <pre wrap="">Where are you looking for the logs? They should be in /var/log/secure on
FC systems.
BTW - you really don't want to set klips/plutodebug=all. You'll get so
much in your logs that you'll probably never find the important stuff.
Comment out or remove those debug lines please.

 

      
          </pre>
          <blockquote type="cite">
            <pre wrap="">    Jul 24 00:12:44 vpn1 ipsec_setup: KLIPS ipsec0 on eth0 
62.189.139.60/255.255.255.0 broadcast 62.189.139.255
    Jul 24 00:12:44 vpn1 ipsec_setup: ...Openswan IPsec started
    Jul 24 00:12:47 vpn1 ipsec__plutorun: 104 "amextunnel" #1: 
STATE_MAIN_I1: initiate
    Jul 24 00:12:47 vpn1 ipsec__plutorun: ...could not start conn 
"amextunnel"

This is my ipsec.conf:

config setup
       interfaces=%defaultroute
       klipsdebug=all
       plutodebug=all
       nat_traversal=yes

conn amextunnel
       type=           tunnel
       left=           62.189.139.60
       leftnexthop=    62.189.139.5
       leftsubnet=     192.168.5.0/24
       right=          89.234.17.132
       rightnexthop=
       rightsubnet=    192.168.201.0/24
       esp=            3des-sha1-96
       keyexchange=    ike
       pfs=            no
       auto=           start


The log entries and results are identical whether I use OE or not.

Anyone have any ideas what might be going on, where to start looking or 
how to get more information out of it?

Thanks in advance,
Matt
_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Users@openswan.org">Users@openswan.org</a>
<a class="moz-txt-link-freetext"
 href="http://lists.openswan.org/mailman/listinfo/users">http://lists.openswan.org/mailman/listinfo/users</a>
Building and Integrating Virtual Private Networks with Openswan: 
<a class="moz-txt-link-freetext"
 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>
          <pre wrap="">_____________________________________________________________________
This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit <a
 class="moz-txt-link-freetext" href="http://www.mci.com">http://www.mci.com</a>
 

      
          </pre>
        </blockquote>
        <pre wrap="">-- 
Matthew Claridge
Product Support Engineer
RWA Limited

Tel: 02920 815 054
Email: <a class="moz-txt-link-abbreviated"
 href="mailto:mclaridge@rwa-net.co.uk">mclaridge@rwa-net.co.uk</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.rwa-net.co.uk">www.rwa-net.co.uk</a>

_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Users@openswan.org">Users@openswan.org</a>
<a class="moz-txt-link-freetext"
 href="http://lists.openswan.org/mailman/listinfo/users">http://lists.openswan.org/mailman/listinfo/users</a>
Building and Integrating Virtual Private Networks with Openswan: 
<a class="moz-txt-link-freetext"
 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>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

    
        </pre>
      </blockquote>
      <pre wrap="">_____________________________________________________________________
This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit <a
 class="moz-txt-link-freetext" href="http://www.mci.com">http://www.mci.com</a>
  
      </pre>
    </blockquote>
    <pre wrap="">-- 
Matthew Claridge
Product Support Engineer
RWA Limited 

Tel: 02920 815 054
Email: <a class="moz-txt-link-abbreviated"
 href="mailto:mclaridge@rwa-net.co.uk">mclaridge@rwa-net.co.uk</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.rwa-net.co.uk">www.rwa-net.co.uk</a>



-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean.
    </pre>
  </blockquote>
  <pre wrap=""><!---->

_____________________________________________________________________
This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit <a
 class="moz-txt-link-freetext" href="http://www.mci.com">http://www.mci.com</a>
  </pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<font size="-1">Matthew Claridge<br>
Product Support Engineer<br>
RWA Limited
</font>
<p><font size="-1">Tel: 02920 815 054<br>
Email: <a class="moz-txt-link-abbreviated"
 href="mailto:mclaridge@rwa-net.co.uk">mclaridge@rwa-net.co.uk</a><br>
Web: <a class="moz-txt-link-abbreviated"
 href="http://www.rwa-net.co.uk">www.rwa-net.co.uk</a></font></p>
</div>
</body>
</html>