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: <CABBfienZDG=kFMfGe=Awa4ZhuhGTRRy7uGcPjWaZLiGi+XWBDA@mail.gmail.com>
Date: Tue, 10 Dec 2024 15:00:03 -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

On Thu, Dec 5, 2024 at 3:00 AM James Chapman <jchapman@...alix.com> wrote:
> Please don't top-post.
Apologies, first timer.
> Are you configuring an IP address on l2tpeth0.1319 and capturing on
l2tpeth0?
I'm running dhclient on  l2tpeth0.1319, the DHCP discover from that is
the packet you see in the screenshot. The pcap is being taken on the
physical interface.


>
> On 04/12/2024 21:04, Preston wrote:
> > 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.
>
> Please don't top-post. It makes it much harder for other readers to
> follow the discussion. I'll repaste your reply below this time.
>
> > 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?
>  >
>  > 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.
>
> Are you configuring an IP address on l2tpeth0.1319 and capturing on
> l2tpeth0?
>
> >>
> >>>
> >>>
> >>> # 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