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: <ed0ffb72-3848-d1be-6903-d6ab21a0f77f@katalix.com>
Date: Thu, 5 Dec 2024 08:00:05 +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 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
>>>
>>
>