[Openswan Users] Trying to find why ipsec0 tx dropped occurs

[Mike C]

On Fri, Jun 11, 2010 at 3:11 PM, Paul Wouters <paul at xelerance.com> wrote:
> On Fri, 11 Jun 2010, Mike C wrote:
>
>> # ping 192.168.25.254
>> PING 192.168.25.254 (192.168.25.254): 56 data bytes
>> ping: sendto: Invalid argument
>
> firewall rule?

No rules are dropping nor NAT'ing any traffic.

I just quickly hacked ipsec_tunnel.c to print out the IP addresses:

# ping 192.168.25.254
PING 192.168.25.254 (192.168.25.254): 56 data bytes
ping: sendto: Invalid argument
# Jun 11 15:36:56 yellowbox user.info kernel:
klips_debug:klips_header_cache: cannot revector dev=ipsec0 op=(null)
func=(null)
Jun 11 15:36:56 yellowbox user.info kernel:
klips_debug:ipsec_tunnel_hard_header: skb->dev=ipsec0 dev=ipsec0.
Jun 11 15:36:56 yellowbox user.info kernel:
klips_debug:ipsec_tunnel_hard_header: cannot revector dev=ipsec0
op=(null) func=(null) ip=c0a812fe->c0a819fe src=192.168.18.254
dst=192.168.25.254

I'm going to look into it further, but for some reason one of the
below conditions is being met in ipsec_tunnel.klips_header

        if(prv->dev->header_ops == NULL ||
                        prv->dev->header_ops->create == NULL) {
...
        }

>> I get these same messages regardless of what machine it is initiated
>> on in the 192.168.18.0/24 network. What is causing the packets to be
>> dropped,and more importantly what needs to be changed?
>>
>> The machine is linux 2.6.32-9, with uClibc and busybox. Perl isn't
>> installed so ipsec verify isn't working.
>
> Usually, NAT'ing ipsec packets causes symptoms like these.

I can confirm that they aren't being NAT'ed - as shown by the above
debugging on ipsec_tunnel.c, plus I added an explicit entry for the
PREROUTING table:

iptables -t nat -I PREROUTING -s 192.168.18.0/24 -d 192.168.25.0/24 -j RETURN
(and its counter isn't incrementing after each ping either)

# iptables -v -n -L PREROUTING -t nat
Chain PREROUTING (policy ACCEPT 3 packets, 191 bytes)
 pkts bytes target     prot opt in     out     source
destination
    0     0 RETURN     all  --  *      *       192.168.18.0/24
192.168.25.0/24

>> Jun 11 09:14:20 testbox user.warn pluto[2204]: "tun1" #5: up-client
>> output: //lib/ipsec/_updown.klips: changesource `ip route change
>> 192.168.25.0/24 dev ipsec0 src 192.168.18.254' failed (RTNETLINK
>> answers: No such file or directory)
>
> You have a leftsourceip= that's outside of leftsubnet= ?

It's definitely within the /24.

>> 94.11.24.57:500 but no connection has been authorized with policy=PSK

Sorry, the logs contained several attempts, after restarting and
wiping all logs I don't see this.

The tunnel is up, as the right was able to send a packet to the left,
but left unable to return the response.

>> Jun 11 09:14:15 testbox user.warn pluto[2204]: time moved backwards 8
>> seconds
>
> That could also temporarilly cause problems.

I'm also not seeing this after a clean restart.

Regards,

Mike