Re: Native Vlan Mismatch

allen.external · ‎12-08-2004

Quick question. If I have two switches connected to each other and one is vlan1 and the other is vlan2 and I am seeing the error native vlan mismatch, how can the two switches talk to each other. If the packet has been assighned vlan 2 on one switch going out a port and on the other switch the packet has assighned vlan 1 ID then how come my servers on one switch can talk to the servers on the other switch? Just a question about theory. Any body have any comments.

Thanks

Justin

andrew.butterworth · ‎12-08-2004

Justin

The link between the 2 switches I assume is an access-port and NOT a trunk port? If this is the case the issue you are seeing is cosmetic and is a result of CDP. Each switch periodically sends out CDP messages; in these messages is the VLAN that the port is configured on. In your case one is set to VLAN1, the other to VLAN2 - a mismatch. The reason you have connectivity is they are access-ports so it is a common VLAN. If the port was a trunk then you would not have connectivity since you would have 2 separate VLAN's.

You can fix this by either reconfiguring the ports to be in the desired VLAN or simply disabling CDP on the port that connects the 2 switches. I would change the ports to be in the same VLAN.

Andy

allen.external · ‎12-08-2004

I guess I dont understand why the switch would not notice packets coming in from vlan 1 and not forward those on to vlan2 ports. What it seems like is we are doing intervlan routing without a router or layer3 switch. And yep, they are not trunk ports.

Thanks,

Justin

jtudong · ‎12-08-2004

The native VLAN packets are sent out untagged. So, each switch assumes that the untagged packets belong on their native VLAN even though it is configured differently. You are not routing packets, you just stumbled onto a loophole.

7rbowenii · ‎12-08-2004

This is not necessarily a loophole. This works as VLANs were designed. A VLAN is simply a grouping of ports in a switch. Each VLAN acts as though it were a seperate switch. It doesn;t require a router for traffic to traverse VLANs, it requires a router or a bridge. In this case, the cable connecting the two switches is acting as the bridging device in this scenario.

It is not until you create a trunk that VLANs are more than a group of ports on a single switch.

-Bo

7rbowenii · ‎12-08-2004

Justin,

Packets traversing non-trunk ports are not tagged, thus the switches don't spearate the traffic. However, CDP does transmit VLAN information, but not for operational purposes, just for informational.

So, CDP will notice the mismatch because the labels on the ports are different, but the traffic is passing from one untagged port to the next, so the traffic appears to be in one vlan. I hope this answers your question.

allen.external · ‎12-08-2004

But it looks Tagged to me. I have attached a screen shot from the NAM. This is from a server port on our switch.

milan.kulik · ‎12-09-2004

But it seems like tagged for VLAN125.

(See http://www.cisco.com/en/US/customer/tech/tk389/tk390/technologies_tech_note09186a0080094665.shtml#topic2)

Are you sure this is not a frame coming FROM

the server misconfigured to tag the frames?

Or isn't VLAN125 configured as a voice VLAN in your network?

AFAIK, when the switch receives a frame tagged for another VLAN on an access port, it should discard it and sent an error message "Received unexpected tagged frame ..." to the syslog.

Regards,

Milan

Kevin Dorrell · ‎12-09-2004

Milan,

Doesn't it forward the frame raw? (It may well generate the syslog message as well.) I thought that was the basis of the VLAN-hopping security hole: if you have an access port on the same VLAN as the native VLAN of your trunks, and you get the host on that port to generate a frame with a (different VLAN) tag, then the switch forwards it raw, possibly to the trunks. Then the other end of the trunks see the tagged frame and interpret it, forwarding it to the VLAN according to the tag inserted by the host.

Isn't that why you should never have access ports on the same VLAN as the trunk native?

Kevin Dorrell

Luxembourg

allen.external · ‎12-09-2004

Wow, I am getting really confused as to what the answer is to this question. I will tell you what. I will go with a sniffer to the switch in question and take a trace. If it comes back without a vlanid then how does the switch know not to foward vlan 2 traffic to vlan 3. For example, lets say half the ports on a switch are vlan 2 and the other half is vlan 3, if the packet comes in on vlan 2 access port and is not marked with some type of vlan id then how does the switch know not to flood this packet to the vlan 3 ports? If somebody could answer that I would greatly appreciate it. Thanks a ton guys Justin

Kevin Dorrell · ‎12-09-2004

This is my understanding of the VLAN-hopping security hole:

Within a switch, traffic stays within the VLAN it came from. If the access port is on VLAN 3, then its traffic stays in VLAN 3, even if the host tries to tag a frame. The security hole comes on the trunk links between switches.

Suppose you have an access port on VLAN 1, but you have also left the native VLAN of your trunks on VLAN 1; i.e. the default condition. Suppose then that someone generates a frame to the access port, and illicitly tags it with VLAN 6. That frame will get flooded in VLAN 1 within the switch, because it was received on a VLAN 1 access port. But what happens when it gets to a trunk ... the trunk will pass it, but will not tag it because it came from the native VLAN. But the switch at the other end of the trunk sees a frame with a VLAN 6 tag, and so forwards it on VLAN 6. Thus VLAN-hopping.

Kevin Dorrell

Luxembourg

milan.kulik · ‎12-09-2004

Kevin,

it could be some kind of VLAN hopping.

But the VLAN hopping trick is a little more complicated, AFAIK, when an access port receives a frame tagged for another VLAN, it simply drops it and generates an error message.

The VLAN hopping scenario is following (See Network security Architectures by Sean Convery, CiscoPress 2004, page 214):

Suppose you have an access port on VLAN1, but you have also left the native VLAN of your trunks on VLAN 1; i.e. the default condition.

Suppose then that someone generates a frame to the access port, and doubletags it with VLAN1 and VLAN125 tags.

When such a double-tagged frames comes to VLAN1 access port, the port has to accept it (802.1q recommendation requires access ports to accept both untagged frames and frames tagged with the access (native) VLAN tages).

The switch strips VLAN1 tag from the incoming frame and sends it to the trunk. VLAN1 is native on the trunk, so the switch doesn't add any new tag to the frame. BUT it doesn't check if there isn't another tag present in the frame already!!!

BUT the frames contained additional VLAN125 frame!

So it passes the trunk and comes to the oposite switch tagged with VLAN125 tag. The switch then has to put it to the VLAN125 access port (or all VLAN125 ports and trunks in an unknown unicats or broadcast case).

This works only in one direction, of course, but could be exploited for some DoS attack, e.g.

But AFAIK, the target port needs to be in VLAN125 in this case and VLAN125 tag should be removed from the outgoing frame. If ports involved are in VLAN1 and VLAN2 and the suspicious frame is tagged for VLAN125, then it might be some modified version of VLAN hopping (tripple-tagging, e.g.) or we are in a bad direction completely.

Regards,

Milan

Kevin Dorrell · ‎12-09-2004

Thanks Milan, I see that now. So the VLAN hopping trick has one more layer of complexity (the double-tag) than I was aware of. That gets around the safeguards of the switch rejecting tagged packets. So the weakness comes down to that part of the spec that states that if an access port receives a frame with the correct tag, then it should strip the tag and pass the remainder. I wonder why they did that? It means you can hide malicious tags simply by putting your own tag on the front.

Interesting exercise for me next time I am in the lab: contrive to generate double-tagged frames to test this. :-{

Kevin Dorrell

milan.kulik · ‎12-10-2004

Hi Kevin,

I think the reason was compatibility with other vendors tagging all frames.

IMHO the weakness is caused via not checking the two bytes following the tag for another tag presence.

I'm not sure how exactly 802.1q-in-q frame header looks like, but I think there should be external DA SA tag followed by internal DA SA tag.

But the malicious frame used for VLAN hopping should look DA SA tag1 tag2.

So it might be possible to check...

Anyway: When you are in your lab, you should use some hacker tool creating "your own design" Ethernet frames. I know there should be some tools available on the internet, but don't know any concrete one.

Please, let me know when your are successful with your test.

Best regards,

Milan

allen.external · ‎12-09-2004

Ok, lets take the trunk out of this all together. I understand how trunks work and how they tag the frame. If there isnt any tagging, when a packet comes in on a access port that is in vlan 2, how does the switch know not to send this to Vlan3 if there isnt any tag or ID of some type on the packet? Does the switch just know that this is a vlan 2 port that the traffic is coming from and it knows only to go to other vlan2 ports or is there some kind of ID that gets put on the packet that tells the switch this is Vlan2?