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

Michael Smith msmith at cbnco.com
Thu Sep 3 16:51:24 EDT 2009

Paul Wouters wrote:
> On Mon, 17 Aug 2009, Evan Doiron wrote:
>>      switch                     soekris
>> ===== ------- -------
>> ====
>> I am able to establish the tunnel, but the route to the peer's client
>> does not come up on either or If I manually
>> create the routes when ipsec is running I can successfully ping from
>> to (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.

Hi Paul,

I think there are a couple of things that Evan was running into when 
upgrading from 2.4.8 to 2.6.22.

The new _updown.netkey script (since commit 4b8b8389) only adds routes 
if it gets a pair of arguments "--route yes", or if 
leftsourceip/rightsourceip are set. Whatever is calling updown doesn't 
pass "--route yes", so routes aren't added for tunnels.

     # skip routing if it's not enabled or necessary
     if [ " $PLUTO_MY_SOURCEIP" = " " -a " $ROUTE" != " yes" ]; then
         return 0

After hacking up the script to hardcode ROUTE=yes, or setting 
leftsourceip, the default behaviour is to add a route out the interface 
if no nexthop is set, which is equivalent to nexthop=%direct. So I guess 
setting leftnexthop=%direct wasn't necessary, but it used to work; now 
confread.c flags "%direct" as invalid, because it only understands 
addresses and "%defaultroute".

For my own purposes I'll probably patch confread.c to ignore %direct, 
patch _updown.netkey to hardcode ROUTE=yes, and start adding 
leftsourceip/rightsourceip to my tunnels. I'm just curious how the 
"--route yes" was intended to be passed.

I guess usually netkey doesn't need routes added -- IF the box has a 
default route. If it doesn't, netkey never gets a chance to see the 
packets; the routing stack returns "no route to host".


>> This is my configuration on the right ( 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=
>>            leftsubnet=
>>            leftid="/O=Test Test SC/OU=test/CN=net5501"
>>            leftca=%same
>>            # Right
>>            right=
>>            rightsubnet=
>>            rightnexthop=%direct
>>            rightid="/O=Test Test SC/OU=test/CN=aqs8322"
>>            rightcert=auto-cert.pem
>>            auto=start

More information about the Users mailing list