[Openswan Users] Openswan-2.6.22: while loading 'test': bad addr rightnexthop=%direct [illegal (non-DNS-name) character in name]
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
>> 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.
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
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 (172.20.22.64) machine:
>> version 2.0
>> config setup
>> nhelpers = 0
>> # Add connections here
>> conn %default
>> conn test
>> # Left
>> leftid="/O=Test Test SC/OU=test/CN=net5501"
>> # Right
>> rightid="/O=Test Test SC/OU=test/CN=aqs8322"
More information about the Users