[Openswan Users] Cannot make openswan working...

Andriy Lesyuk s-andy at in.if.ua
Mon Apr 28 06:54:47 EDT 2008


Hello,

I have spent many hours trying to make Openswan working. No success for now.

First, this is my configuration:

o Openswan 2.4.6
o Debian kernel 2.6.18 patched with klips and natt (for Openswan version 
2.4.6).

/etc/ipsec.conf is:

   1.
      version 2.0
   2.
       
   3.
      config setup
   4.
          nat_traversal=yes
   5.
          interfaces=ipsec0=eth1
   6.
          rp_filter=0
   7.
          syslog=local6.info
   8.
          #plutodebug=all
   9.
          dumpdir=/etc/ipsec.d
  10.
         
      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
  11.
          strictcrlpolicy=yes
  12.
       
  13.
      conn nung-server
  14.
          type=tunnel
  15.
          left=X.X.X.X
  16.
          leftcert=ipsec-cert.pem
  17.
          right=%any
  18.
          rightsubnet=vhost:%no,%priv
  19.
          rightrsasigkey=%cert
  20.
          leftprotoport=17/1701
  21.
          rightprotoport=17/1701
  22.
          authby=rsasig
  23.
          keyingtries=3
  24.
          pfs=no
  25.
          auto=add
  26.
          rekey=no
  27.
       
  28.
      # Disable Opportunistic Encryption
  29.
      include /etc/ipsec.d/examples/no_oe.conf

/etc/ipsec.secrets:

   1.
      : RSA /etc/ipsec.d/private/ipsec-key.pemversion 2.0

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:

iptables -I INPUT -s Y.Y.Y.Y -j DROP

But no firewall rules there. In other words - no packets arrive to 
X.X.X.X from Y.Y.Y.Y any more...

This is what I see in logs:

   1.
      Apr 27 02:16:57 base pluto[17849]: packet from y.y.y.y:500:
      ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
   2.
      Apr 27 02:16:57 base pluto[17849]: packet from y.y.y.y:500:
      ignoring Vendor ID payload [FRAGMENTATION]
   3.
      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
   4.
      Apr 27 02:16:57 base pluto[17849]: packet from y.y.y.y:500:
      ignoring Vendor ID payload [Vid-Initial-Contact]
   5.
      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
   6.
      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
   7.
      Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #5:
      STATE_MAIN_R1: sent MR1, expecting MI2
   8.
      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
   9.
      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
  10.
      Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #5:
      STATE_MAIN_R2: sent MR2, expecting MI3
  11.
      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 & Networking Lab., CN=email, E=email'
  12.
      Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #5: I
      am sending my cert
  13.
      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
  14.
      Apr 27 02:16:57 base pluto[17849]: | NAT-T: new mapping
      y.y.y.y:500/61121)
  15.
      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}
  16.
      Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #6:
      responding to Quick Mode {msgid:284397ed}
  17.
      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
  18.
      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
  19.
      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
  20.
      Apr 27 02:16:57 base pluto[17849]: "nung-server"[4] y.y.y.y #6:
      STATE_QUICK_R2: IPsec SA established {ESP=>0x5f05f00d <0x5aad9757
      xfrm=3DES_0-HMAC_MD5NATD=y.y.y.y:61121 DPD=none}

As I understood - no errors here, right?

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

But I have some thoughts:

The virtual_private is defined as follows:

%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

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

Thanks! Any help will be greatly appreciated.
Andriy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20080428/6aa20f90/attachment.html 


More information about the Users mailing list