[Openswan dev] decrypted packet appears at wrong ipsec interface

hiren joshi joshihirenn at gmail.com
Mon Sep 1 10:50:09 EDT 2008


Hello,

Many thanks for your quick replay.

>> I use openswan-2.4.8 (KLIPS).
>
> That is VERY old.

Actually I am waiting for the compression bug to be solved.
http://lists.openswan.org/pipermail/dev/2008-August/001913.html
Bug report: http://bugs.xelerance.com/view.php?id=982

> So I think you are seeing the 'normal' behaviour here.

Digging the code, found that: ipsec0 is forced to be used for NATed connections.

ipsec_rcv.c:
int klips26_rcv_encap(struct sk_buff *skb, __u16 encap_type)
{
        struct ipsec_rcv_state nirs, *irs = &nirs;
        struct iphdr *ipp;

        /* Don't unlink in the middle of a turnaround */
        KLIPS_INC_USE;

        memset(irs, 0, sizeof(*irs));

        /* XXX fudge it so that all nat-t stuff comes from ipsec0    */
        /*     eventually, the SA itself will determine which device
         *     it comes from
         */
        {
          skb->dev = ipsec_get_device(0);
        }

Curious on the reason for this fudging.

With following experiment, I see packet traversal as per my
expectation: eth1 -> ipsec0, eth2 -> ipsec1

int klips26_rcv_encap(struct sk_buff *skb, __u16 encap_type)
{
        ...

        /* XXX fudge it so that all nat-t stuff comes from ipsec0    */
        /*     eventually, the SA itself will determine which device
         *     it comes from
         */
        {
                if (strcmp(skb->dev->name, "eth1") == 0)
                        skb->dev = ipsec_get_device(0);
                else if (strcmp(skb->dev->name, "eth2") == 0)
                        skb->dev = ipsec_get_device(1);
        }

Thanks for your time.

Regards,
-hiren


More information about the Dev mailing list