[Openswan Users] Openswan-2.6.22: while loading 'test': bad addr rightnexthop=%direct [illegal (non-DNS-name) character in name]

[Evan Doiron]

Paul Wouters wrote:
> On Mon, 17 Aug 2009, Evan Doiron wrote:
>
>>      switch                     soekris
>>    192.168.2.0/24 ===== 172.20.22.66 ------- 172.20.22.60 -------
>> 172.20.22.64 ==== 192.168.1.0/24
>>
>> I am able to establish the tunnel, but the route to the peer's client
>> does not come up on either 172.20.22.66 or 172.20.22.64. If I manually
>> create the routes when ipsec is running I can successfully ping from
>> 192.168.2.2 to 192.168.1.2 (Clients from either end). The problem
>> happens when i specify the leftnexthop and or rightnexthop in the
>> ipsec.conf file. I get the error "while loading 'test': bad addr
>> rightnexthop=%direct [illegal (non-DNS-name) character in name]".
>
> I think it is type=%direct? But I don't think you need it.
>
>> This is my configuration on the right (172.20.22.64) machine:
>>
>>    version    2.0
>>
>>    config setup
>>        nat_traversal=yes
>>        oe=off
>>        protostack=netkey
>>        nhelpers = 0
>>
>>    # Add connections here
>>    conn %default
>>            keyingtries=0
>>            disablearrivalcheck=no
>>            authby=rsasig
>>            leftrsasigkey=%cert
>>            rightrsasigkey=%cert
>>            ike=aes256-sha,aes256-md5
>>            esp=aes256-sha1,aes256-md5
>>
>>    conn test
>>            # Left
>>            left=172.20.22.66
>>            leftsubnet=192.168.2.0/24
>>            leftid="/O=Test Test SC/OU=test/CN=net5501"
>>            leftca=%same
>>            # Right
>>            right=172.20.22.64
>>            rightsubnet=192.168.1.0/24
>>            rightnexthop=%direct
>>            rightid="/O=Test Test SC/OU=test/CN=aqs8322"
>>            rightcert=auto-cert.pem
>>            auto=start
>
> try: rightnextop=172.20.22.66
>
>> STATE_QUICK_I1 to state STATE_QUICK_I2
>> Aug 17 13:51:39 aqs8322 pluto[732]: "test" #2: STATE_QUICK_I2: sent QI2,
>> IPsec SA established tunnel mode {ESP=>0x170dc92f <0x445beb06
>> xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=none}
>
> the tunnel came up
>
>> Aug 17 13:51:44 aqs8322 pluto[732]: "test" #4: STATE_QUICK_R2: IPsec SA
>> established tunnel mode {ESP=>0x53d9f09d <0x662f0c69
>> xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=none}
>
> and again.
>
> So I think you need to check firewall rules, forwarding, etc.
>
> Paul
Hi Paul,

I gave your suggestion of specifying the nexthops explicitly a try, and
unfortunately I am still unable to successfully ping from client to
client, as no route comes up.
I am running the openswan instances on two soekrises with no firewalls
running, and all forwarding enabled. As I do not wish to set a default
route,
I need this route to come up to be able to interact from client to client.

Perhaps I am mistaken but basically what I'm expecting is that a route
should come up to the peer's client when the tunnel has been established.
I am upgrading from OpenSwan 2.4.x on a 2.6.x kernel to 2.6.22, has the
support for %direct gone?

The logs look the same as before except this error: "while loading
'test': bad addr rightnexthop=%direct [illegal (non-DNS-name) character
in name]" is now gone,
but I noticed a few other errors in the logs that might help:

        ipsec_setup: Command line is not complete. Try option "help"
        pluto[2766]: myid malformed: empty string ""

Any help is greatly appreciated. Thanks again,

-Evan

-- 
Evan Doiron
Software Developer Co-op
Canadian Bank Note Company Limited
edoiron at cbnco.com