[Openswan Users] Good old "cannot identify ourselves" and %defaultroute issue...

[Marc]

Hi...

I found this thread in last month's archive and I am experiencing virtually the same issue. I get the error
pluto: "vpn-conn": We cannot identify ourselves with either end of this connection.

I have two openSuSE 11.1 boxes, one working, the other not. I copied the whole /etc/ipsec* files from the working one to the other, and just changed the approriate section regarding ip net and certificate

Both systems have the same Kernel and ipsec version:

# uname -a
Linux kmlulx05 2.6.27.21-0.1-pae #1 SMP 2009-03-31 14:50:44 +0200 i686 athlon i386 GNU/Linux

# ipsec --version
Linux Openswan U2.6.16/K2.6.27.21-0.1-pae (netkey)

On the non-working system I have the following:

# ip route
217.0.118.44 dev dsl0  proto kernel  scope link  src 91.17.225.140 
192.168.63.0/24 dev eth0  proto kernel  scope link  src 192.168.63.10 
10.63.63.0/24 dev eth1  proto kernel  scope link  src 10.63.63.63 
169.254.0.0/16 dev eth0  scope link 
127.0.0.0/8 dev lo  scope link 
default dev dsl0  scope link 

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet 127.0.0.2/8 brd 127.255.255.255 scope host secondary lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:10:18:4e:5b:af brd ff:ff:ff:ff:ff:ff
    inet 192.168.63.10/24 brd 192.168.63.255 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:22:19:1c:d2:64 brd ff:ff:ff:ff:ff:ff
    inet 10.63.63.63/24 brd 10.63.63.255 scope global eth1
6: dsl0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3
    link/ppp 
    inet 91.17.225.140 peer 217.0.118.44/32 scope global dsl0

# cat /etc/ipsec.conf
# basic configuration
### Converted to version 2.0 ipsec.conf by freeswan %post
version 2.0

config setup
        protostack=netkey
        forwardcontrol=yes
        klipsdebug=none
        nat_traversal=yes
        uniqueids=yes
        plutowait=yes
        plutodebug=none
        plutodebug=all

conn %default
        keyingtries=0
        compress=yes
        disablearrivalcheck=no
        authby=rsasig
        leftrsasigkey=%cert
        rightrsasigkey=%cert

conn vpn-conn
        right=%defaultroute
        rightsourceip=192.168.63.10
        rightcert=linux2.pem
        rightid="C=DE, L=Local, O=My Organization, CN=linux2"
        leftid="C=DE, L=Remote, O=My Organization, CN=gateway"
        leftcert=gateway.pem
        left=11.12.13.14    # original has correct address
        leftsubnet=192.168.1.0/24
        rightsubnet=192.168.63.0/24
        auto=start


### Added by freeswan %post
# Switch off Opportunistic Encryption policies -- BEGIN
conn block
        auto=ignore
conn private
        auto=ignore
conn private-or-clear
        auto=ignore
conn clear-or-private
        auto=ignore
conn clear
        auto=ignore
conn packetdefault
        auto=ignore
#conn OEself
#       auto=ignore
# Switch off Opportunistic Encryption -- END



Now, if I change the %defaultroute to 91.17.225.140 (the dsl ip), the vpn connection starts and is working normally. As this is a dynamic addres though, I have to rely on the %defaultroute entry. Where should I look for further clues why this system acts like this, while its sister system works as intended?

In the syslog I noticed another strange entry:

    ipsec_setup: Starting Openswan IPsec 2.6.16...
    ipsec_setup: No KLIPS support found while requested, desperately falling back to netkey
    ipsec_setup: NETKEY support found. Use protostack=netkey in /etc/ipsec.conf to avoid attempts to use KLIPS. Attempting to continue with NETKEY

Since I have the appropriate entry in the config setup section, at first I suspected the system doesn't read the config file, but since it does read the connections, and it loads the appropriate certificates, I am left clueless here, too.

Any help on this issue would be appreciated.


So long,
                     Marc...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090716/12a4108d/attachment.html