VLAN and VPN

Your last line is circular reasoning. It could be that there were some layer 2 facets that there was some choice about in implementing a layer 2 VPN, with a standard arising to unify the choices, but with it still (hypothetically) being perfectly possible to do layer 2 VPNs. Any given standard does not have to introduce new functionality: it could instead act to normalize existing functionality.

Before answering the question, I would want to know what they meant by VPN and what they meant by VLAN. For example, is it possible to use MLPS to implement a private layer 2 extension to a LAN that was carrying 802.1Q packets? (As far as I understand, Yes). Can GRE be used to encapsulate layer 2 packets, with or without ISL tags? (Sure can.) Can PIX 6.3 be configured to sit on an 802.1Q tagged trunk and see foreign-destined IP packets with any given

802.1Q tag, and forward those on (stripped of tag) over an IPSec VPN? (Yes.) Will PIX 6.3 preserve random 802.1Q tags in regular traffic over an IPSec VPN (no, it will ignore the packets unless configured to have a "logical interface" in that VLAN.)

Hi,

Thanks for your reply.

I am not entirely familair with all the things you mentioned, but the question was actually very general. They simply asked if VLAN would in any way be compatible with VPN technically and if yes, if it would be 'a good idea' to implement such a configuration.

Now, I am pretty sure that it is technically possible to implement VPN in a VLAN, but I am not sure if this would be ethically correct with the OSI concept of layers. So that's basically what I'm asking here.

Thanks.

circular reasoning. It could be that there

I still can't understand the reason for your confusion. L2 VLANs are completely transparent at L3, so questions about VPNs being in any way "compatible with" or "ethical correct within" VLANs are moot. The two technologies do not provide even remotely similar functionality, so what is your actual problem?

Hi,

Let me try to explain my difficulty: For example, a VLAN **can** be configured by IP-addresses, but it's not recommended to do this because by doing so you're allowing ip-headers to be opened in layer 2, which is not correct considering the OSI model. However, it is technically possible to do it.

My question is now if there isn't a similair "concern" when using VPN on a VLAN ?

Thanks.

can't understand the reason for your confusion. L2 VLANs are

I see, so you are referring to non-802.1p/q VLANs? It's probably not an "ethernet" question then. Actually, the last time I saw "IP header based" VLANs was on an old Intel EtherExpress Switch from the pre-standards-era some years ago. I would not primarily argue against it using the "OSI model" argument, but rather the "management" argument - it's really a nightmare to have something which is completely dynamic and uncontrollable from a supporter's perspective.

There is nothing wrong with valid L3 traffic over L2 transports. It does not matter if the L3 traffic is some kind of a tunneling protocol set. If you have a VPN client on your notebook and your internet connectivity happens to be available through a transit network using VLANs, why should there be any argument against its legitimate use to transport the payload?

elesser wrote in part:

Yes, technically there is this concern. You might be skipping a layer, and using L3 or even L4 to carry L2 traffic.

I'm not worried. I see the value in the OSI model as standarizing the layer interfaces rather than forcing all traffic through layers sequentially.

-- Robert

According to

operates at Layer 3, Network layer, which is the same layer as IP. But IPSec provides for the ability to create Security Associations according to protocol and port -- e.g., to tunnel TCP 23 (telnet) while UDP 53 (DNS) was left to go through the regular network. In order to provide this kind of selective service, the device implementing IPSec has to peak at the layer 5 (Application Layer) headers, and upon a match, encapsulate the Layer 5 packets at layer 2 (ESP / AH) or layer 3 (IPSec over UDP). Lots of layer breaking there.

Even if the Security Associations are set up by IP, you still have the possibility of encapsulating IPSec within UDP (or TCP), which is Layer 3 encapsulated within Layer 4. This would, in the ideal layering model, not be "ethically correct". Is it a good idea, though? Well, it allows IPSec to work through intermediate networks that do NAT (Network Address Translation), so from the point of view of getting the job done it is a good idea. On the other hand, as people such as Melinda Shore might argue, implementing one more wart to work around the problems of NAT is likely not doing anyone any favours in the long run -- it is too much like painting over rotten wood.

Minor correction: that should be peak at layer 5 and encapsulate at layer 3 or layer 4.

Actually, it is often recommended to create VLANs based on IP addresses, and it is commonly done. Don't let the layered model be a straight-jacket on functionality. Let the *applications* and *user requirements* drive network functions, and use the "layering" to explain what is being done, not to limit what should be done.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Actually, the one thing the OSI model (along with the OSI protocols) does *not* do is to "standardize the layer interfaces." Interfaces between layers (if a layered implementation even exists) are completely internal to the device, and need not be uniform among devices. There is no general benefit to forcing implementors to use some form of "standard interface."

What the OSI model (and the protocol standards) often do is to specify the inter-layer interfaces in a formal, abstract manner, so that the protocol can be defined in terms of its operation on the parameters of that abstracted interface. This in no way is a mandate for implementors to build their systems such that the inter-layer interfaces correspond to the abstract model; in fact, smart designers rarely (if ever) do.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Thank you for the correction. I think my terminology was wrong: I agree that how the data is moved within or between the layers is deliberately unspecified and creativity is encouraged. But the start- and end-points of that movement (the fields in the packet) _are_ defined (for the various alternatives at each layer) to permit interoperability. Not that new definitions are discouraged too much either, but they must be standardized. IMHO, That standardization plus the very separation into layers are big contributions of the OSI model.

-- Robert

Hi,

I agree that IP-based routing is commonly done in VLANs, but I still feel that something isn't right about doing it. Let me quote a phrase from "Computer Networks" by A.S. Tanenbaum (4th edition, section 4.7.6 Virtual LANs, page 333): "Of course, there is nothing wrong with routing based on IP addresses - nearly all of Chap. 5 is devoted to IP routing - but mixing the layers is looking for trouble." Looks like there's someone who agrees with me...

Btw, thanks guys for all the replies, they're really helpful!!!

recommended to create VLANs based on IP addresses,

recommended to create VLANs based on IP addresses,

Firstly a couple of things:- It is not clear that your use of terminology is exactly the same as mine.

VLAN - Layer 2 (e.g. Ethernet) broadcast domain. VPN - Secure (encrypted) communications over an insecure network. Very commonly IPSEC at present however there are alternatives.

The L2 broadcasts are tunneled over the L3 network.

Your original question:-

"Is it possible to use a VPN connection on a VLAN ?". Is I feel poorly posed and has no simple answer.

"Is it possible to use a VPN connection on a VLAN ?". Discuss - 30 minutes writing time. In this case it is clear that no simple answer is expected.

There is no reason at all that a VPN cannot be implemented in a single broadcast domain such that traffic between two particular applications on two particular hosts was encrypted when it was traversing the network defined by the broadcast domain.

A simple example (crypto - simple?) is WPA on 802.11 wireless networks.

One thing to remember is that a VLAN can be implemented over a L3 network and this is a common way for network providers to deliver long distance services.

In my premises in London UK I get an ethernet port that /is/ in the same broadcast domain as another ethernet port in Houston Texas. However the traffic is actually carried by the service provider over an IP network.

I think that you are a bit muddled up with a lot of this. Mixing layers is done all of the time. Layer (x) traffic is usually carried by Layer (x-1), however as, hopefully, illustrated this is not necessarily always the case.

I am a network implementation and support Engineer and in my work the layered model is of value for classifying and isolating network activity which helps with design and troubleshooting. Unfortunately reams and reams of paper have been produced about the "ISO OSI 7 LAYER MODEL" which has magnified the importance of the detail in the definition of the layers. This has also provided ready examination fodder for [lazy] examiners.

I think that for a user of network equipment what really matters is the concept of layering and since it is so widely used in the language of networking it is also critical to be able to translate the various terms used.

In ethernet terms:- L1 - wires and signalling, repeaters (now not manufactured) - send and receive bits

L2 - MAC addresses, frames, CRC, bridges (now called switches) - send and receive frames to the extent of a broadcast domain

L3 - IP adresses, packets, ARP, routers (now sometimes called switches) - send and receive packets across the explored universe

L4 - TCP/UDP - - - Well I can't do as well as Andrew Tannenbaum so - I will point you back there. You may also - consider Rich Seifert's "The switch Book".

Keep studying - One of the fun things about this work is that there is always more to learn. For may people the only way to get to really understand this is to work with it.

The other day a friend who is beginning to study networks asked something like -

"I don't understand, how does the message know where to go. If I go to a computer and want to send a message to you how does it find you."

I said, don't worry about that for now, just worry about how two computers can ping each other. This was considered unsatisfactory and time did not permit further discussion.

Sadly I failed to explain anything. He has been confused somehow by some reading and it will take some time to get unconfised.

That highlights a /very/ good use for a layered model - as an aid in teaching networking, learn one layer at a time:-)))

I posed virtually the same question as my very first utterance in an undergraduate networking class I taught at UC Santa Cruz. All of the students were "Internet savvy," that is, they were experienced Internet

*users*, but none could answer the fundamental question of "What happens when you press the 'Send' button on an email?"

The answer was a 10 week course introductory course on computer networks.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

VPN in an of itself doesn't imply security. It is common to find security as one aspect of VPNs but there are unsecure VPNs as well, such as L2VPNs provided by MPLS. VPN is basically a service where multiple customers can build private networks using shared infrastructure.

I agree with this. Really the question is so general that the answer would be "yes". There is nothing preventing you from using a VPN connection on a VLAN. Think about what happens at conventions. Everyone on the wireless network is typically on a single VLAN. However, they are all connected (using some client software) into respective corporate VPNs.

Anoop

snipped-for-privacy@hotmail.co.uk wrote in part:

The short answer: messages are like hot potatoes: each computer along the way sends it in the direction it thinks (routing tables) will get it closer to it' destination. The details are very complex, but `traceroute`, or TRACERTE.EXE on some MS systems shows the path.

-- Robert

Traceroute only shows what the path might have been under certain circumstances, not what the path actually was or is going to be. That's the beauty of the construct.