<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Tahoma">Hello,<br>
<br>
I have spent many hours trying to make Openswan working. No success for
now.<br>
<br>
First, this is my configuration:<br>
<br>
o Openswan 2.4.6<br>
o Debian kernel 2.6.18 patched with klips and natt (for Openswan
version 2.4.6).<br>
<br>
/etc/ipsec.conf is:<br>
</font></font>
<div class="syntax">
<div class="text" style="font-family: monospace;">
<ol>
  <li class="li1">
    <div class="de1">version 2.0</div>
  </li>
  <li class="li2">
    <div class="de2"> </div>
  </li>
  <li class="li1">
    <div class="de1">config setup</div>
  </li>
  <li class="li2">
    <div class="de2">    nat_traversal=yes</div>
  </li>
  <li class="li1">
    <div class="de1">    interfaces=ipsec0=eth1</div>
  </li>
  <li class="li2">
    <div class="de2">    rp_filter=0</div>
  </li>
  <li class="li1">
    <div class="de1">    syslog=local6.info</div>
  </li>
  <li class="li2">
    <div class="de2">    #plutodebug=all</div>
  </li>
  <li class="li1">
    <div class="de1">    dumpdir=/etc/ipsec.d</div>
  </li>
  <li class="li2">
    <div class="de2">   
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.44.68.0/24,%v4:!192.168.0.0/20,%v4:!172.27.172.0/24</div>
  </li>
  <li class="li1">
    <div class="de1">    strictcrlpolicy=yes</div>
  </li>
  <li class="li2">
    <div class="de2"> </div>
  </li>
  <li class="li1">
    <div class="de1">conn nung-server</div>
  </li>
  <li class="li2">
    <div class="de2">    type=tunnel</div>
  </li>
  <li class="li1">
    <div class="de1">    left=X.X.X.X</div>
  </li>
  <li class="li2">
    <div class="de2">    leftcert=ipsec-cert.pem</div>
  </li>
  <li class="li1">
    <div class="de1">    right=%any</div>
  </li>
  <li class="li2">
    <div class="de2">    rightsubnet=vhost:%no,%priv</div>
  </li>
  <li class="li1">
    <div class="de1">    rightrsasigkey=%cert</div>
  </li>
  <li class="li2">
    <div class="de2">    leftprotoport=17/1701</div>
  </li>
  <li class="li1">
    <div class="de1">    rightprotoport=17/1701</div>
  </li>
  <li class="li2">
    <div class="de2">    authby=rsasig</div>
  </li>
  <li class="li1">
    <div class="de1">    keyingtries=3</div>
  </li>
  <li class="li2">
    <div class="de2">    pfs=no</div>
  </li>
  <li class="li1">
    <div class="de1">    auto=add</div>
  </li>
  <li class="li2">
    <div class="de2">    rekey=no</div>
  </li>
  <li class="li1">
    <div class="de1"> </div>
  </li>
  <li class="li2">
    <div class="de2"># Disable Opportunistic Encryption</div>
  </li>
  <li class="li1">
    <div class="de1">include /etc/ipsec.d/examples/no_oe.conf</div>
  </li>
</ol>
</div>
</div>
<small>/etc/ipsec.secrets:<br>
</small>
<ol>
  <li class="li1">
    <div class="de1">: RSA /etc/ipsec.d/private/ipsec-key.pemversion 2.0<br>
    </div>
  </li>
</ol>
<small>For now it tries to connect and I don't see any errors... Before
this pluto used to crash often (eg, with different value for
rightsubnet). The problem is that when it seems to be connected any
connectivity with X.X.X.X seems to disappear. Technicaly it looks like
there was added a rule to firewall on X.X.X.X which looks like:<br>
<br>
<font face="Terminus">iptables -I INPUT -s Y.Y.Y.Y -j DROP</font><br>
<br>
</small><small>But no firewall rules there. </small><small>In other
words - no packets arrive to X.X.X.X from Y.Y.Y.Y any more...<br>
<br>
This is what I see in logs:<br>
</small>
<div class="syntax">
<div class="text" style="font-family: monospace;">
<ol>
  <li class="li1">
    <div class="de1">Apr 27 02:16:57 base pluto[17849]: packet from
y.y.y.y:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]</div>
  </li>
  <li class="li2">
    <div class="de2">Apr 27 02:16:57 base pluto[17849]: packet from
y.y.y.y:500: ignoring Vendor ID payload [FRAGMENTATION]</div>
  </li>
  <li class="li1">
    <div class="de1">Apr 27 02:16:57 base pluto[17849]:
packet from y.y.y.y:500: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02_n] method set to=106</div>
  </li>
  <li class="li2">
    <div class="de2">Apr 27 02:16:57 base pluto[17849]: packet from
y.y.y.y:500: ignoring Vendor ID payload [Vid-Initial-Contact]</div>
  </li>
  <li class="li1">
    <div class="de1">Apr 27 02:16:57 base pluto[17849]:
"nung-server"[4] y.y.y.y #5: responding to Main Mode from unknown peer
y.y.y.y</div>
  </li>
  <li class="li2">
    <div class="de2">Apr 27 02:16:57 base pluto[17849]:
"nung-server"[4] y.y.y.y #5: transition from state STATE_MAIN_R0 to
state STATE_MAIN_R1</div>
  </li>
  <li class="li1">
    <div class="de1">Apr 27 02:16:57 base pluto[17849]:
"nung-server"[4] y.y.y.y #5: STATE_MAIN_R1: sent MR1, expecting MI2</div>
  </li>
  <li class="li2">
    <div class="de2">Apr 27 02:16:57 base pluto[17849]:
"nung-server"[4] y.y.y.y #5: NAT-Traversal: Result using
draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed</div>
  </li>
  <li class="li1">
    <div class="de1">Apr 27 02:16:57 base pluto[17849]:
"nung-server"[4] y.y.y.y #5: transition from state STATE_MAIN_R1 to
state STATE_MAIN_R2</div>
  </li>
  <li class="li2">
    <div class="de2">Apr 27 02:16:57 base pluto[17849]:
"nung-server"[4] y.y.y.y #5: STATE_MAIN_R2: sent MR2, expecting MI3</div>
  </li>
  <li class="li1">
    <div class="de1">Apr 27 02:16:57 base pluto[17849]:
"nung-server"[4] y.y.y.y #5: Main mode peer ID is ID_DER_ASN1_DN:
'C=UA, ST=Ivano-Frankivsk, L=Ivano-Frankivsk, O=National University of
Oil and Gas, OU=Software &amp; Networking Lab., CN=email, E=email'</div>
  </li>
  <li class="li2">
    <div class="de2">Apr 27 02:16:57 base pluto[17849]:
"nung-server"[4] y.y.y.y #5: I am sending my cert</div>
  </li>
  <li class="li1">
    <div class="de1">Apr 27 02:16:57 base pluto[17849]:
"nung-server"[4] y.y.y.y #5: transition from state STATE_MAIN_R2 to
state STATE_MAIN_R3</div>
  </li>
  <li class="li2">
    <div class="de2">Apr 27 02:16:57 base pluto[17849]: | NAT-T: new
mapping y.y.y.y:500/61121)</div>
  </li>
  <li class="li1">
    <div class="de1">Apr 27 02:16:57 base pluto[17849]:
"nung-server"[4] y.y.y.y #5: STATE_MAIN_R3: sent MR3, ISAKMP SA
established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192
prf=oakley_sha group=modp2048}</div>
  </li>
  <li class="li2">
    <div class="de2">Apr 27 02:16:57 base pluto[17849]:
"nung-server"[4] y.y.y.y #6: responding to Quick Mode {msgid:284397ed}</div>
  </li>
  <li class="li1">
    <div class="de1">Apr 27 02:16:57 base pluto[17849]:
"nung-server"[4] y.y.y.y #6: transition from state STATE_QUICK_R0 to
state STATE_QUICK_R1</div>
  </li>
  <li class="li2">
    <div class="de2">Apr 27 02:16:57 base pluto[17849]:
"nung-server"[4] y.y.y.y #6: STATE_QUICK_R1: sent QR1, inbound IPsec SA
installed, expecting QI2</div>
  </li>
  <li class="li1">
    <div class="de1">Apr 27 02:16:57 base pluto[17849]:
"nung-server"[4] y.y.y.y #6: transition from state STATE_QUICK_R1 to
state STATE_QUICK_R2</div>
  </li>
  <li class="li2">
    <div class="de2">Apr 27 02:16:57 base pluto[17849]:
"nung-server"[4] y.y.y.y #6: STATE_QUICK_R2: IPsec SA established
{ESP=&gt;0x5f05f00d &lt;0x5aad9757
xfrm=3DES_0-HMAC_MD5NATD=y.y.y.y:61121 DPD=none}<br>
    </div>
  </li>
</ol>
</div>
</div>
<small>As I understood - no errors here, right?<br>
<br>
I wonder if this is due to KLIPS? Will NETKEY solve the problem? I
would like to remain on Openswan 2.4.6... I know that there is newer
versiob but this one is in official Debian repository so it is easier
to maintain. Any suggestion how to solve the issue? Maybe there are
some errors in my config file? Any way I don't understand how and why I
can loose any connectiovity with the server after trying to connect
(ping, ssh etc)...<br>
<br>
But I have some thoughts:<br>
<br>
The virtual_private is defined as follows:<br>
<br>
</small>%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.44.68.0/24,%v4:!192.168.0.0/20,%v4:!172.27.172.0/24<small><br>
<br>
That is all possible virtual nets minus nets used on the server
(10.44.68.0/24, 192.168.0.0/20, 172.27.172.0/24). On the client side I
use 192.168.14.0/24 for local net. May be this is the problem? Can
192.168.14.0/24 be used on the client side if 192.168.0.0/20 is used on
the server side? If not - how I can connect to the server then? May I
exclude 192.168.0.0/20 from the virtual_private? What if I do? If
192.168.14.0/24 cannot be used with Openswan because the server uses
192.168.0.0/20 then, perhaps, Openswan is not what I need... :( But I
believe there should be some solution? For example, can I create some
special net for Openswan so it won't care about local nets (like it is
done in OpenVPN)?<br>
<br>
Thanks! Any help will be greatly appreciated.<br>
Andriy<br>
</small>
</body>
</html>