[Openswan Users] packets get dropped by the ipsec

[Egor N. Martovetsky]

Hi Paul,

I changed my network configuration so that the 2 hosts live on different 
networks.
Also, I am now using 2.4.10 Openswan release.  However, I'm still having 
the same problem.
I can establish the tunnel just fine, like before, but the ping from 
right host to left host gets
dropped by ipsec.  The KLIPS debug message is still the same:

klips_debug:   IP: ihl:20 ver:4 tos:0 tlen:84 id:0 DF frag_off:0 ttl:64 
proto:1 (ICMP) chk:2815 saddr:10.1.12.146 daddr:10.1.15.23 type:code=8:0
klips_debug:ipsec_xmit_strip_hard_header: Original head,tailroom: 2,28
klips_debug:ipsec_findroute: 10.1.12.146:0->10.1.15.23:0 1
klips_debug:rj_match: * See if we match exactly as a host destination
klips_debug:rj_match: ** try to match a leaf, t=0pc00000000f540980
klips_debug:rj_match: *** start searching up the tree, t=0pc00000000f540980
klips_debug:rj_match: **** t=0pc00000000f5409b0
klips_debug:rj_match: **** t=0pc00000000f7473f8
klips_debug:rj_match: ***** cp2=0pc00000003a9b70e8 cp3=0pc000000036a0b0e0
klips_debug:rj_match: ***** not found.
klips_debug:ipsec_xmit_SAlookup: checking for local udp/500 IKE packet 
saddr=a010c92, er=0p0000000000000000, daddr=a010f17, er_dst=0, proto=1 
sport=0 dport=0
klips_debug:ipsec_xmit_encap_bundle: shunt SA of DROP or no eroute: 
dropping.
klips_debug:ipsec_tunnel_start_xmit: encap_bundle failed: 2
klips_debug:ipsec_tunnel_hard_header: skb->dev=ipsec0 dev=ipsec0.
klips_debug:ipsec_tunnel_hard_header: Revectored 
0p0000000000000000->0pc000000000bb29c4 len=84 type=2048 dev=ipsec0->eth1 
dev_addr=00:14:1e:fd:0a:55 ip=0a010c92->0a010f17
klips_debug:ipsec_xmit_strip_hard_header: >>> skb->len=98 
hard_header_len:14 00:14:1e:fd:0a:55:00:14:1e:fd:0a:55:08:00

Here is my current ipsec.conf
# basic configuration
config setup
        # plutodebug / klipsdebug = "all", "none" or a combation from below:
        # "raw crypt parsing emitting control klips pfkey natt x509 private"
        # eg: plutodebug="control parsing"
        #
        # ONLY enable plutodebug=all or klipsdebug=all if you are a 
developer !!
        #
        # NAT-TRAVERSAL support, see README.NAT-Traversal
        nat_traversal=no
        # 
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
        #
        # enable this if you see "failed to find any available worker"
        nhelpers=0
        plutodebug="all"
        klipsdebug="all"
 
 
# Add connections here
 
conn host-to-host
    esp=aes-sha1
    left=10.1.15.23                # Local vitals
    leftid=@xy.example.com         #
    leftrsasigkey=0sAQNoHv793N...
    right=10.1.12.146              # Remote vitals
    rightid=@ab.example.com        #
    rightrsasigkey=0sAQN6oME3t...
    auto=add                       # authorizes but doesn't start this
                                   # connection at startup
 
# sample VPN connections, see /etc/ipsec.d/examples/
 
#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf

At this point, I have no more ideas to try. I wish I could see a 
klips_debug output from
a working host-to-host tunnel.


Egor N. Martovetsky wrote:

>Paul, thanks for your help.
>
>I tried your suggestion, but it doesn't like type=%direct,
>when I try to add connection, it complains:
>
>ipsec auto --add host-to-host
>ipsec_auto: fatal error in "host-to-host": unknown type "%direct"
>
>I will try to setup a tunnel between different networks next, unless
>I get another suggestion.
>
>Paul Wouters wrote:
>
>
>>On Fri, 26 Oct 2007, Egor N. Martovetsky wrote:
>>
>> 
>>
>>
>>>example to set up a host-to-host tunnel using 2 machines on the same subnet
>>>running 2.6.22 kernel.
>>>
>>>things were working fine when I was using kernels with NETKEY.  The pings from
>>>one
>>>machine made it to the other through the tunnel.  However, I realized I need
>>>to use KLIPS in order to get hw acceleration through OCF, so that's what I'm
>>>using now.
>>>
>>>the connection is still established, but the pings to the left machine from
>>>right machine
>>>get dropped by ipsec at the source machine.
>>>   
>>>
>>>
>>   leftnexthop=10.1.12.146        # correct in many situations
>>   right=10.1.12.146              # Remote vitals
>>
>>Can you try commenting out leftnexthop and adding type=%direct ?
>>(or add a "router" between the two machines for a proper test)
>>
>>Paul
>> 
>>
>>
>
>


-- 
Egor N. Martovetsky