KLIPS and 802.1q

> I read the FAQ entry about VLAN with OpenS/WAN [1] and
thought that it
> should work. My impression was that ESP over VLAN is a
supported
> scenario.

> However, outgoing traffic (simple ICMP echo requests)
gets stuck, the
> TX error counter of the ipsec0 interface will increase
with each
> packet. I use Linux 2.6.19 and OpenS/WAN 2.4.7.

> Debugging revealed that the ESP packets seem to be
dropped in
> linux/net/ipv4/route.c:ip_route_output_slow(). More
specific, the
> __in_dev_get_rtnl() call in this function returns NULL.
In the
> consequence, ipsec_tunnel_send() fails at the
ip_route_output_key()
> call.

> My ipsec0 interface is tied to the VLAN interface of
eth0:

> $ whack --status | head -1
> 000 interface ipsec0/eth0.0004 192.168.151.1

> However, in ip_route_output_slow(), dev_out points to
eth0 instead of
> eth0.0004. As eth0 has no IP configured, the
__in_dev_get_rtnl() call
> fails. If I force dev_out to point to eth0.0004, the
ESP packets are
> transmitted and the VPN works.

> Is this a bug? Or is this scenario not supported at
all?

Hi!

I have the same problem on 2.6.18 kernel and Openswan
2.4.7.
When using KLIPS, and ipsec0 is pointed to VLAN interface
(interfaces="ipsec0=vlan0010"), tunnel establishes
connection,
but can't transmit any data. TX errors counter on ipsec0
increases
with each packet transmitted.

When using NETKEY, everything works fine, but without ipsecX
devices... :(((

Any ideas?....

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

On Tue, 29 May 2007, Mikhail Pustovit wrote:

> I have the same problem on 2.6.18 kernel and Openswan
2.4.7.
> When using KLIPS, and ipsec0 is pointed to VLAN
interface
> (interfaces="ipsec0=vlan0010"), tunnel
establishes connection,
> but can't transmit any data. TX errors counter on
ipsec0 increases
> with each packet transmitted.

It should work fine. Can you enable klipsdebug briefly to
see what is
happening:

ipsec klipsdebug --all
[send a few packets]
ipsec klipsdebug --none

Be carefull, this will generate a LOT of logs per packet.

It should give some information as to why the packets are
being dropped.

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

On Tue, May 29, 2007 at 22:19:09 -0400, Paul Wouters wrote:
> On Tue, 29 May 2007, Mikhail Pustovit wrote:
> 
> > I have the same problem on 2.6.18 kernel and
Openswan 2.4.7.
> > When using KLIPS, and ipsec0 is pointed to VLAN
interface
> > (interfaces="ipsec0=vlan0010"), tunnel
establishes connection,
> > but can't transmit any data. TX errors counter on
ipsec0 increases
> > with each packet transmitted.
> 
> It should work fine. Can you enable klipsdebug briefly
to see what is
> happening:
> 
> ipsec klipsdebug --all
> [send a few packets]
> ipsec klipsdebug --none
> 
> Be carefull, this will generate a LOT of logs per
packet.
> 
> It should give some information as to why the packets
are being dropped.

Hi,

I already gave some information where the packets disappear,
see my
first mail in this thread (Message-ID:
<20070521143004.GC8788tkeitel002.bln.innominate.local>). The kernel
tries use eth0 for routing, instead of the VLAN interface,
and fails.

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

On Wed, May 30, 2007 at 10:46:25 +0200, Tino Keitel wrote:
> On Tue, May 29, 2007 at 22:19:09 -0400, Paul Wouters
wrote:
> > On Tue, 29 May 2007, Mikhail Pustovit wrote:
> > 
> > > I have the same problem on 2.6.18 kernel and
Openswan 2.4.7.
> > > When using KLIPS, and ipsec0 is pointed to
VLAN interface
> > > (interfaces="ipsec0=vlan0010"),
tunnel establishes connection,
> > > but can't transmit any data. TX errors
counter on ipsec0 increases
> > > with each packet transmitted.
> > 
> > It should work fine. Can you enable klipsdebug
briefly to see what is
> > happening:
> > 
> > ipsec klipsdebug --all
> > [send a few packets]
> > ipsec klipsdebug --none
> > 
> > Be carefull, this will generate a LOT of logs per
packet.
> > 
> > It should give some information as to why the
packets are being dropped.
> 
> Hi,
> 
> I already gave some information where the packets
disappear, see my
> first mail in this thread (Message-ID:
> <20070521143004.GC8788tkeitel002.bln.innominate.local>). The kernel
> tries use eth0 for routing, instead of the VLAN
interface, and fails.

I looked into it again. Openswan supplies a struct flowi to
ip_route_output_key():

	struct flowi fl;
 	fl.oif = ixs->physdev->iflink;
 	if ((ixs->error =
ip_route_output_key(&ixs->route, &fl))) {


The kernel then uses fl->oif to get the
physical device:

dev_out = dev_get_by_index(oldflp->oif);

However, eth0 and eth0.0004 (my VLAN interface) share the
same iflink
number:

$ cat /sys/class/net/eth0/iflink
/sys/class/net/eth0.0004/iflink
2
2

So the kernel uses the first interface that has this iflink
number,
which is eth0. Then the kernel tries to route the packet
over eth0, and
fails.

Could it be that the line

fl.oif = ixs->physdev->iflink;

should actually be

fl.oif = ixs->physdev->ifindex;

because the ifindex number is different for both interfaces?
The
dev_get_by_index() usage also looks like ifindex is more
appropriate
than iflink.

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

On Wed, May 30, 2007 at 18:56:27 +0200, Tino Keitel wrote:

[...]

> Could it be that the line
> 
> fl.oif = ixs->physdev->iflink;
> 
> should actually be
> 
> fl.oif = ixs->physdev->ifindex;
> 
> because the ifindex number is different for both
interfaces? The
> dev_get_by_index() usage also looks like ifindex is
more appropriate
> than iflink.

I just tried it, and it works.

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

  Hi,

On Wednesday 30 May 2007 19:09, Tino Keitel wrote:
> > Could it be that the line
> >
> > fl.oif = ixs->physdev->iflink;
> >
> > should actually be
> >
> > fl.oif = ixs->physdev->ifindex;
> >
> > because the ifindex number is different for both
interfaces? The
> > dev_get_by_index() usage also looks like ifindex
is more appropriate
> > than iflink.
>
> I just tried it, and it works.

  Confirmed. I've found the same problem about a month ago
and this change 
has solved it. (Sorry, I forgot to send the patch to this
list.)

  Oh, and BTW the KLIPS debug message is problematic, too.
If you enable 
klipsdebug all you get is a nice OOPS message.

  Patches attached.

-- 
 Regards,
  Krisztian Kovacs

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