On Tue, 3 Jan 2006, Marco Berizzi wrote:

> I have enabled klipsdebug=all, and I have found why I
see dropped TX packets
> on ipsec0 interface.
> This is my network diagram:
>
> ---priv1_net---|swan1
box|---eth0_pub_ip-*internet*-pub_ip_eth0---|swan2
> box|---priv2_net
>
> I'm pinging a non-existent system on the priv1_net from
a priv2_net host and
> the swan1
> box is generating an icmp host unreachable packet with
source IP=eth0_pub_ip
> and
> destination IP=priv2_net host. This packet is then
routed through ipsec0 and
> it is
> dropped by KLIPS. I don't understand why the linux box
is generating the icmp
> packet
> with source ip=eth0_pub and not with the priv1_net ip
assigned to itself (on
> eth1). Is this
> the correct behaviour? What should I do to have the
icmp unreach response back
> to the
> original client on the priv2_net (if possible)?

that's odd, it shouldnt be accepted by klips as there is no
policy for it.

A workaround I can think of is to use
leftsourceip=priv1_netip on swan1 box, which
might trigger the icmp message source address to be the
private instead of public
address.

Alternatively, you can create eth0_pub_ip-priv2subnet
tunnels (eg create not only
subnet-subnet, but host-subnet, subnet-host and host-host
tunnels) to cover the
current icmp packet with an ipsec policy.

I am not sure if this should be considered a bug in openswan
or in the linux kernel.

Anyone on the dev list have the answer to this one?

Paul
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev

Paul Wouters wrote:

>On Tue, 3 Jan 2006, Marco Berizzi wrote:
>
> > This is my network diagram:
> >
> > ---priv1_net---|swan1
box|---eth0_pub_ip-*internet*-pub_ip_eth0---|swan2
> > box|---priv2_net
> >
> > I'm pinging a non-existent system on the priv1_net
from a priv2_net host 
>and
> > the swan1
> > box is generating an icmp host unreachable packet
with source 
>IP=eth0_pub_ip
> > and
> > destination IP=priv2_net host. This packet is then
routed through ipsec0 
>and
> > it is
> > dropped by KLIPS. I don't understand why the linux
box is generating the 
>icmp
> > packet
> > with source ip=eth0_pub and not with the priv1_net
ip assigned to itself 
>(on
> > eth1). Is this
> > the correct behaviour? What should I do to have
the icmp unreach 
>response back
> > to the
> > original client on the priv2_net (if possible)?
>
>that's odd, it shouldnt be accepted by klips as there is
no policy for it.

Sorry, I don't understand you. Why is this odd? I don't see
anything wrong.
Perhaps I didn't clearly explain myself. These packets *are*
routed through
ipsec0 because of the openswan's route add:

Destination     Gateway         Genmask         Flags   MSS
Window  irtt 
Iface
priv2_net    cisco_pub_ip_1      priv2_net_mask   UG       
0 0          0 
ipsec0

but these packets are *not* accepted by KLIPS. They are
correctly dropped 
with
this error:

ipsec_xmit_encap_bundle: shunt SA of DROP or no eroute:
dropping

because there is no policy for those one's as you wrote.
Correct?

>A workaround I can think of is to use
leftsourceip=priv1_netip on swan1 
>box, which
>might trigger the icmp message source address to be the
private instead of 
>public
>address.

Aha! Yes, now it is working  I also
successfully tried the same trick 
with netkey
(2.6.14.3). I'm now getting back "Destination Host
Unreachable" messages.
I'm happy  [I'm
going to update all my openswan box]

>I am not sure if this should be considered a bug in
openswan or in the 
>linux kernel.

I *think* linux is generating the icmp message with source
ip=eth0_pub_ip 
because
of the following openswan added route:

Destination     Gateway         Genmask         Flags   MSS
Window  irtt 
Iface
priv2_net    cisco_pub_ip_1      priv2_net_mask   UG       
0 0          0 
ipsec0

IMHO this isn't a openswan bug nor a kernel bug. Perhaps the
route addition
on netkey boxes could be considered an openswan bug.

Thanks a lot for the reply.

PS: When was introduced left-right-sourceip parameter? May
you update man
page?


_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev