[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