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

Paul Wouters paul at xelerance.com
Mon Aug 17 17:53:19 EDT 2009


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


More information about the Users mailing list