Hi, I have a very simple question for layrer 2 switch behaviour,
what will happen if a switch receive a 802.1Q tagged frame on its port and the port is not tagged for that vlan but tagged for other vlans.
But the switch is configured for that VLAN on other ports.
Please comments how switch will behave,
will he receives the tagged frame and forwards to other ports OR will switch ignores the tagged frame.
it would be great if you please answer in the light of HP procurve 2610 and Cisco 2950 switches, if there is any difference in behaviour.
your reply will be very helpful.
modern LAN switches like 4506 with new IOS code are able to filter these tagged frames on ports in access mode if the vlan id is different from the one defined on the port
int type x/y
switchport mode access
switchport access vlan y
Older switches like some CatOS 5500 switches forward these tagged frames.
To be noted there are other more sophisticated vlan hopping attacks using a double 802.1Q tag:
this second attack works if the native vlan on 802.1Q trunks is the same as that on the access port.
So another suggestion is to reserve a vlan to be used only as native vlan on 802.1q trunks and for nothing else different from vlan1
Unused ports should be put in a different vlan (parking vlan) with no L3 services.
Not sure about C2950 but it should be able to defeat single vlan tagging attacks.
I did some L2 security tests some years ago.
Hope to help
I can confirm that for the 2950:
"An access port belongs to and carries the traffic of only one VLAN. Traffic is received
and sent in native formats with no VLAN tagging. Traffic arriving on an access port is
assumed to belong to the VLAN assigned to the port. If an access port receives a tagged
packet (Inter-Switch Link [ISL] or 802.1Q tagged), the packet is dropped, the source
address is not learned, and the frame is counted in the No destination statistic. An
access port can not forward a tagged packet (802.1P and 802.1Q)."
-----> The only exception is if the switch supports "voice vlan" and has it configured but for the 2950 is not even an option.
As far as I know, the 2950 do support the voice VLAN. What did you mean by saying that "it is not even an option"?
Moreover, that article you have posted does not actually seem to apply. I have routinely demonstrated the VLAN hopping using double-tagged 802.1Q frames on 2950 series.
VLAN hopping is another case here, the question is about receiving tags in "access ports" and forwarding them out "access ports".
Hopping needs a trunk for the attack to be effective.
2950 no PoE support but OK you could say you could still use a voice vlan and as this is kind of a 1 vlan trunk then receiving tags on this vlan will of course make the switch forward them out all other ports in that vlan
Thank you for your reply.
I think that the PoE is not a topic of discussion here.
Regarding the VLAN hopping: yes, you are correct, it needs a trunk with a suitable native VLAN to be effective. I was just commenting the fact that the 2950 accepts a tagged port even on an access port without any voice VLAN. Frankly, I am not quite sure if it will forward a tagged frame out an access port but I am sure that it will accept a tagged frame on such port.
I think an access port should accept untagged frames or frames tagged with a vlan-id = access vlan-id.
This is the basis for the double 802.1Q vlan hopping that can happen if a trunk has native vlan = access vlan on the port receiving the attack frame.
Then the voice vlan is a special case that makes the port a mini trunk able to carry only two vlans:
untagged native vlan = data access vlan
tagged vlan = voice vlan
POE should be out of context here.
Hope to help
There have been differences how 2950 and 2960 accept tagged frames on their access ports. I honestly do not remember the details but I am going to test them tomorrow and I will post the results here.
So I've made a couple of experiments with 2950 and 2960 series switches, individually on each one. I created three VLANs, 10, 20 and 555. Then, I configured ports fa0/1 and fa0/2 as access ports and assigned them both into VLAN10. Then, using the 'yersinia' software under Linux (a very handy tool indeed! :), I have been sending tagged and double-tagged frames to the fa0/1 port and observed the output of the fa0/2 port using Wireshark.
The results for 2950 are as follows:
An access port will accept 802.1Q tagged frames if and only if their VID is either 0 or equal to the access VLAN of the port (in my case, the VLAN 10 was used). Frames with different tags will be discarded. If a tagged frame is accepted on an access port according to the condition above, the first tag will be stripped when sending that frame out some other access port. If the accepted frame was double tagged, only the first tag is removed, not the subsequent tags. If a tagged frame that was accepted on an access port is to be sent out a trunk port, the usual rules for tagging apply: either all tags will remain in place (with VID 0 being replaced with the VID of the access port), or the first tag will be stripped if its VID equals to the native VLAN of the trunk.
For the 2960 series, the results are similar but there is an additional requirement: an access port must be configured with a voice VLAN, otherwise all tagged frames will be dropped no matter what VID they have. If a voice VLAN is configured on an access port then all rules and behavior patterns from 2950 series apply, i.e., the VID must be either 0 or the access VLAN, and the behavior when switching that frame to a different port is identical to 2950 series.
So to summarize all this, access ports do accept tagged frames. However, the tags must be either set to 0 or to the VLAN of the access port itself. On 2960, there is an additional requirement - a voice VLAN must be configured on that access port. If a tagged frame accepted on an access port is sent out from another access port, the first tag will be stripped. If such frame is sent out from a trunk port, the first tag will be stripped if it equals to the native VLAN of the trunk, otherwise all tags will remain in position.