Community discussions

 
Gombeen666
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 61
Joined: Tue Jun 25, 2019 5:33 pm

Test for leaking VLAN's

Fri Aug 23, 2019 4:11 pm

Is it possible to check on a network for leaking vlan packets from other vlans ?
 
mkx
Forum Guru
Forum Guru
Posts: 3210
Joined: Thu Mar 03, 2016 10:23 pm

Re: Test for leaking VLAN's

Fri Aug 23, 2019 4:28 pm

First off you have to decide how you're supposed to see that a packet has leaked to the wrong VLAN. VLAN ID is obviously a wrong choice (specially so in the untagged section of a VLAN). You could look for packets with sender/receiver MAC address which are not supposed to be in the observed VLAN ... or something else.

When you know what you're looking for you can build a detection system ...
BR,
Metod
 
anav
Forum Guru
Forum Guru
Posts: 3129
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Test for leaking VLAN's

Sat Aug 24, 2019 12:07 am

Yes, vlans wont leak unless you have misconfigured your router.
Suggest you post your config for evaluation.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
Gombeen666
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 61
Joined: Tue Jun 25, 2019 5:33 pm

Re: Test for leaking VLAN's

Sat Aug 24, 2019 12:14 am

For starters I would like to test that for example - Mikrotik router A should be getting only tagged VLAN packets for two Vlan's ID=1010 and 1020, then router B should be getting tagged VLAN packets for another two vlan's ID= 2010 and 2020 ?
 
sindy
Forum Guru
Forum Guru
Posts: 4008
Joined: Mon Dec 04, 2017 9:19 pm

Re: Test for leaking VLAN's

Sat Aug 24, 2019 10:18 am

For starters I would like to test that for example - Mikrotik router A should be getting only tagged VLAN packets for two Vlan's ID=1010 and 1020, then router B should be getting tagged VLAN packets for another two vlan's ID= 2010 and 2020 ?
First of all think about how the switching and bridging works. Once a frame from a given unicast MAC has been received through any port of the bridge or switch, that MAC address associates with that port and until the association either times out or gets rewritten by arrival of a frame from the same MAC address through another port, all frames for that MAC address are only send out via that port.

So to test for leaks, you have to make sure that you either send the test frames to a multicast MAC address or that you send them to a unicast MAC address which doesn't exist in your network, which always causes the frames to be sent out all ports., or that you have manually associated a destination address with a particular port on which you want to test, which may not be always possible (especially when a switch chip is involved) but if it is, it causes the frames to be sent through that single port only. So when I do things like this, I manually set arp records binding an unused IP address to an unused MAC address on an L3 interface which would be the /interface vlan in your case and expect them to be broadcast via all switch/bridge ports.

The second thing is where to look for the leaked frames. Since there is often a switch chip between the CPU (where the sniffing actually takes place) and the wire, to be sure whether the frame has reached the wire or not you always have to look for the leaked frames at the other end of the wire. Also, if you use the switch chip for forwarding, make sure that you nject the frames you suspect to possibly leak also from other ingress ports, not just from the CPU. The switch chips normally take the decision what to do with the frame already at ingress.

And the third thing is how to detect leaked frames on the remote side. Of course the key is that the test receiver would neither filter by VLAN tag nor remove the tag (as most Windows drivers and reportedly also some Linux drivers do). If the test receiver is another Mikrotik, you can use /tool sniffer to see what exactly is coming in, but you can also use /interface bridge filter rules to just count frames matching the vlan ID you look for, e.g. chain=input action=accept in-interface=ether1 src-mac-address=34:CA:6D:00:00:00/FF:FF:FF:00:00:00 mac-protocol=vlan vlan-id=1020, chain=forward action=accept in-interface=ether1 src-mac-address=34:CA:6D:00:00:00/FF:FF:FF:00:00:00 mac-protocol=vlan vlan-id=1020. Of course, the ingress port you use for the test must be a member port of some bridge on the test receiver if you want to use /interface bridge filter rules, and hw=no must be set in the corresponding /interface bridge port row; if you use the sniffer, it is better that the ingress port used as test receiver is not a member of any bridge and has no IP configuration attached.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.

Who is online

Users browsing this forum: No registered users and 49 guests