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

[Michael Smith]

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.

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
     fi

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

Mike

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