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: <3e6af55f-3270-604b-c134-456200188f94@katalix.com>
Date: Wed, 4 Dec 2024 11:48:33 +0000
From: James Chapman <jchapman@...alix.com>
To: Preston <preston@...rpreston.com>
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: ethernet over l2tp with vlan

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
>