EBTables vs VLAN - Testing Network Isolation OSI Layer

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking
Author Message
MonarchX
DD-WRT User


Joined: 26 Sep 2009
Posts: 78

PostPosted: Wed May 12, 2021 11:18    Post subject: EBTables vs VLAN - Testing Network Isolation OSI Layer Reply with quote
How do you test local network isolation without knowing router settings? For example, how can you tell whether 2 devices are isolated on Layer 2 of OSI model or on Layer 3? Both Layer 2 and Layer 3 isolation prevent all inbound and outbound TCP, UDP, ICMP, and I think IGMP packet exchange between isolated devices. I assume ARP detection is the key because one device can see ARP requests & replies of another device with Layer 3 isolation, but not with Layer 2 isolation. Is there some other way to test without knowing router settings and without presence of VLAN tags?

Accessing my UniFi Dream Machine's config files and SH scripts via SSH/SCP shows that "L2 Isolation" WiFi setting coupled with Guest Policies (without Captive Portal) is based on EBTables rather than IPTables. Unlike IPTables that affect Layer 3 packets, EBTables affect Layer 2 frames.

There are no VLAN's on my network yet because none of the WLAN devices can see each other's ARP requests/replies, but WLAN devices can see local DNS server (which runs on Ethernet port) during authorization process. What kind of isolation is it then? Hybrid?

What is the difference between isolating devices with EBTables VS VLAN's, aside from VLAN tagging capabilities?
Sponsor
Per Yngve Berg
DD-WRT Guru


Joined: 13 Aug 2013
Posts: 6128
Location: Romerike, Norway

PostPosted: Thu May 13, 2021 18:30    Post subject: Reply with quote
VLAN operates at layer 1.

It's like having two switches that are not inter-connected. A client on switch A cannot reach a client on switch B.
MonarchX
DD-WRT User


Joined: 26 Sep 2009
Posts: 78

PostPosted: Sat May 15, 2021 23:28    Post subject: Reply with quote
My reasoning is this:
VLAN is still virtual LAN. There is no physical barrier between VLAN's on the same switch. As such, VLAN on the same switch can only be software-based. VLAN is only Layer 2 isolation, not Layer 1 isolation. Layer 1 is the physical separation, Layer 2 is the data link separation.

IPTables works on Layer 3 while EBTables works on Layer 2. Ubiquiti's WiFi Guest isolation configuration files show that UDM's Guest isolation is accomplished via IPTables and EBTables, but there is much more to Netfilter than IPTables and EBTables.

Then there is the port isolation that can also exist on the same switch, but I think it can also accomplished via Netfilter - https://help.ui.com/hc/en-us/articles/360039311974-EdgeSwitch-EdgeSwitch-X-Port-Isolation .

Basically, I think both VLAN isolation and port isolation are software-based Netfilter rules.

Am I wrong somewhere?
tedm
DD-WRT User


Joined: 13 Mar 2009
Posts: 431

PostPosted: Sun May 16, 2021 1:35    Post subject: Re: EBTables vs VLAN - Testing Network Isolation OSI Layer Reply with quote
MonarchX wrote:
How do you test local network isolation without knowing router settings? For example, how can you tell whether 2 devices are isolated on Layer 2 of OSI model or on Layer 3? Both Layer 2 and Layer 3 isolation prevent all inbound and outbound TCP, UDP, ICMP, and I think IGMP packet exchange between isolated devices. I assume ARP detection is the key because one device can see ARP requests & replies of another device with Layer 3 isolation, but not with Layer 2 isolation. Is there some other way to test without knowing router settings and without presence of VLAN tags?


You can't.

MonarchX wrote:

What is the difference between isolating devices with EBTables VS VLAN's, aside from VLAN tagging capabilities?


For starters keep in mind that ebtables is a Linux-open-source-thingie, a software program that does networking stuff.

VLANS are networking stuff. You are basically using them in an apples to oranges comparison. I _THINK_ you actually mean MAC-address filtering when you say ebtables but I am not sure.

A VLAN is nothing more than a regular packet with a couple bytes added to it for a tag. IF you have a VLAN-aware smart switch, like a Cisco Catalyst for example, you can go to each port of the switch and tell it to subscribe to a particular VLAN or to all of them. In that case a device on a port WILL NOT see ANYTHING other than the packets for that VLAN. The packets will (usually) have the tag stripped off of them in this configuration before they exit the switch.

If OTOH you have a basic dumb switch that does not understand 802.1q VLAN tags then what happens is undefined. First the 802.1q tagged packets will have a non-standard ethertype specified in the frame which it may care about - if so, it may drop it as damaged. If it doesn't care about them it will just pass them on. Second, any packet with a size of 1500 will actually be 1502 or something and if the switch is strict about the size it may ignore it.

I have also found through testing with Windows clients that MANY network adapter drivers don't even have a way of specifying a VLAN tag on a packet. Microsoft punted VLANs to the ethernet chip makers and the driver must have support and many chip makers were lazy and didn't even put VLAN support into their Windows drivers. There's chips out there where you can boot the computer on Windows and there's no way to make the client issue a VLAN-tagged packet, while you can boot the same hardware on Linux and send VLAN-tagged packets all day long.

Essentially VLAN tagged packets are used here:

1) On WANS if you have a metro area ethernet connection to a provider you might need to tag the frames you send it

2) In collections of smart switches at a larger network (like for example a college dormitory) to create separate networks because it is hard to control a network with a thousand or so hosts on it with a subnet mask of 255.255.0.0 the broadcasting alone will kill you. In this situation routing between the VLAN networks usually happens INSIDE a switch.

3) In IP Telephony work on very large campuses because they can prioritize packets on VLAN2 and assign that to the phones. Then phone calls won't get disrupted by broadcast storms or someone downloading something big. Since the windows (or whatever) clients don't speak VLAN they cannot even receive a tagged packet, it's dropped by their network drivers long before their networking stack sees it. In fact many VoIP phones have 2 ports on them, one that is plugged into the switch and the other that is available for a PC to plug into.

Now as far as MAC address filtering - that's done on UNFRAMED packets not tagged packets. A packet traveling THROUGH a router has the tagging stripped off it it when it is received by the first interface before it's handed to the routing engine, or to ebtables, or any of that.
MonarchX
DD-WRT User


Joined: 26 Sep 2009
Posts: 78

PostPosted: Sun May 16, 2021 11:04    Post subject: Reply with quote
IPTables controls Layer 3 packets, while EBTables controls Layer 2 frames.

EBTables can be used to filter actual frames of Data Link Layer 2, even if they are not assigned any IP addresses. For example, EBTables can filter INPUT, FORWARD, and OUTPUT frames of MAC addresses, LLDP, ARP, tagged VLAN frames, WoL, and many more.

You can create EBTables rules that can prevent all Layer 2 frames from crossing from one client to another.

IPTables can only perform partial MAC filter and only when MAC addresses have IP addresses assigned to them. IPTables you can only specify INPUT and FORWARD rules for MAC address control. There is no way to control MAC address OUTPUT with IPTables. You can only do it with EBTables.

VLAN = Layer 2 isolation. EBTables controls Layer 2 frames and EBTables rules can prevent Layer 2 frames from crossing from one client to another. Therefore VLAN = EBTables rules. VLAN's can be tagged or untagged. I don't know if EBTables can assign tags...

Not being able to test whether there is Layer 2 isolation can't be true... At the very least manufacturers test their own switches to find out of VLAN options work. How do you know if router/switch VLAN option even works if you can't test it? I think running TCPDump to filter for EtherType frame sources should work... TCPDump can detect both Layer 2 (EtherType) frames and Layer 3 packets. I think that if you try to send a Layer 2 frame from one client (sender) to another client (receiver) and TCPDump does not detect that frame on the (receiving) client, then both clients are isolated from each other on Layer 2 of the OSI model. I don't know how to do that.

TCPDump shows that Layer 3 isolation allows clients to see ARP requests and replies of other clients on the same network, but Layer 2 isolation does not. That makes sense because ARP is a Layer 2 protocol, but ARP is just one of many Layer 2 protocols. How do you test all Layer 2 protocols at once? There are many EtherType frame types out there...
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum