[Openswan dev] WinXP L2TP disconnects as small UDP packets can not pass the tunnel

Paul Wouters paul at xelerance.com
Sat Nov 22 01:49:06 EST 2008


On Wed, 19 Nov 2008, hiren joshi wrote:

Hi Hiren,

> Problem:
> NATed L2TP connection with Windows XP (SP2) terminates after 1 minute.

> - Win XP sends L2TP control packets that are 52 bytes in length after
> ESP+UDP encapsulation.
> - These packets are dropped (ipsec klipsdebug --all) by the following code:
>
> linux/net/ipsec/ipsec_esp.c::ipsec_rcv_esp_checks
>
>        if(skb->len < (irs->hard_header_len + sizeof(struct iphdr) +
> sizeof(struct esphdr))) {
>                KLIPS_PRINT(debug_rcv & DB_RX_INAU,
>                            "klips_debug:ipsec_rcv: "
>                            "runt esp packet of skb->len=%d received
> from %s, dropped.\n",
>                            skb->len,
>                            irs->ipsaddr_txt);
>                if(irs->stats) {
>                        irs->stats->rx_errors++;
>                }
>                return IPSEC_RCV_BADLEN;
>        }
>
> Allowing these packets (removing - return IPSEC_RCV_BADLEN;) solves the problem.
>
> pinging with -s 0 shows that  skb->len = Payload(0) + ICMP (8) + IP
> (20) + ESP (16) + UDP (16) = 60.

Indeed, that is problematic. I wonder when Windows started sending these
short packets, because I have not seen this before. But obviously the
check in openswan is wrong.

> This happens only when ipsec0 is attached with ppp0.
> It doesn't happen when: ipsec0 -> ethX and ipsec1 -> ppp0.
> Perhaps due to fudging ipsec0 (ipsec_rcv.c::klips26_rcv_encap),
> hard_header_len is calculated 14 (ethernet) instead of 22 (ppp).

> It also do not happen with xl2tpd client :).

> I am not familiar with the code.
> Is changing the condition a right thing to do?
> How can I put it only for NATed packets?

For now I have commented out the check. AFAIK, it is only used to
drop obviously bogus packets without wasting cpu cycles on trying
to decrypt them, but as you demonstrated, that check as currently
implemented is wrong.

Thank you very much for this information. It muts have been a
time consuming bug hunt. I really appreciate you sharing this
with us.

Paul


More information about the Dev mailing list