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-next>] [day] [month] [year] [list]
Message-ID: <CABBfiem067qtdVbMeq2bGrn-5bKZsy_M8N-4GkE0BO6Uh7jX1A@mail.gmail.com>
Date: Tue, 3 Dec 2024 11:14:58 -0500
From: Preston <preston@...rpreston.com>
To: netdev@...r.kernel.org
Subject: ethernet over l2tp with vlan

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.

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


# 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ