netdev - Re: ethernet over l2tp with vlan

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABBfie=3+NBmjpVHn8Ji7VakEo9-JMKDH3ut5d1nXnDneC0tPw@mail.gmail.com>
Date: Wed, 4 Dec 2024 16:04:57 -0500
From: Preston <preston@...rpreston.com>
To: James Chapman <jchapman@...alix.com>
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: ethernet over l2tp with vlan

l2tpeth0 is not attached to anything, it's created by the `ip l2tp`
commands. But since it's encapsulating and setting a new destination
IP address, packets are referred to the route table.

On Wed, Dec 4, 2024 at 6:48 AM James Chapman <jchapman@...alix.com> wrote:
>
> On 03/12/2024 16:14, Preston wrote:
> > Hello folks, please let me know if there’s a more appropriate place to
> > ask this but I believe I’ve found something that isn’t supported in
> > iproute2 and would like to ask your thoughts.
>
> Thanks for reaching out.
>
> > I am trying to encapsulate vlan tagged ethernet traffic inside of an
> > l2tp tunnel.This is something that is actively used in controllerless
> > wifi aggregation in large networks alongside Ethernet over GRE. There
> > are draft RFCs that cover it as well. The iproute2 documentation I’ve
> > found on this makes it seem that it should work but isn’t explicit.
> >
> > Using a freshly compiled iproute2 (on Rocky 8) I am able to make this
> > work with GRE without issue. L2tp on the other hand seems to quietly
> > drop the vlan header. I’ve tried doing the same with a bridge type
> > setup and still see the same behavior. I've been unsuccessful in
> > debugging it further, I don’t think the debug flags in iproute2's
> > ipl2tp.c are functional and I suppose the issue might instead be in
> > the kernel module which isn’t something I’ve tried debugging before.
> > Is this a bug? Since plain ethernet over l2tp works I assumed vlan
> > support as well.
> >
> >
> > # Not Working L2TP:
> > [root@...rf1 ~]# ip l2tp add tunnel tunnel_id 1 peer_tunnel_id 1 encap
> > udp local 2.2.2.2 remote 1.1.1.1 udp_sport 1701 udp_dport 1701
> > [root@...rf1 ~]# ip l2tp add session tunnel_id 1 session_id 1 peer_session_id 1
> > [root@...rf1 ~]# ip link add link l2tpeth0 name l2tpeth0.1319 type vlan id 1319
> > [root@...rf1 ~]# ip link set l2tpeth0 up
> > [root@...rf1 ~]# ip link set l2tpeth0.1319 up
> > Results: (captured at physical interface, change wireshark decoding
> > l2tp value 0 if checking yourself)
> > VLAN header dropped
> > Wireshark screenshot: https://i.ibb.co/stMsRG0/l2tpwireshark.png
>
> This should work.
>
> In your test network, how is the virtual interface l2tpeth0 connected to
> the physical interface which you are using to capture packets?
>
> >
> >
> > # Working GRE:
> > [root@...rf1 ~]# ip link add name gre1 type gretap remote 1.1.1.1
> > [root@...rf1 ~]# ip link add name gre1.120 link gre1 type vlan proto
> > 802.1q id 120
> > [root@...rf1 ~]# ip link set gre1 up
> > [root@...rf1 ~]# ip link set gre1.120 up
> > Results:
> > VLAN header present
> > Wireshark screenshot: https://i.ibb.co/6rJWjg9/grewireshark.png
> >
> >
> > -------------------------------------------------------
> > ~Preston Taylor
> >
>


-- 
-------------------------------------------------------
~Preston Taylor