Basic question about Management VLANs

[sbgoodwin]

This is a really really basic, and probably stupidly obvious question, but I just can't seem to figure it out, and it been a constant source of head scratching for me.

I have two vlans. Vlan 2 is for data, and vlan 3 is for voice.  I changed the default management vlan from 1 to 2, because I need to manage the router.
Whenever I've tried to make a seperate management vlan, I get locked out of the router because I can't reach that subnet (which is the point, as far as security is concerned). So how do I adhere to best practices and create a management vlan, and be able to access that vlan?  My computer needs to be on vlan 2 because I am also a user of that vlan...

Can anyone explain what is typically done so that sys admins can access their management vlans?  Is this done through ACL's, or maybe a static route for only certain ip/mac addresses?

Thanks for any pointers, and sorry for what is likely a very basic question.  Always learning ;-)

[Ryan Wolfe]

If your management VLAN was accessible from your other VLANs, it would defeat the purpose. You're segmenting your management traffic from the rest of your user accessible networks. In order to access them, you'll have to have a client on a management VLAN.

Otherwise, you can apply an ACL to your VTY lines that denies all traffic other than your management clients.

Sent from Cisco Technical Support iPhone App

[sbgoodwin]

Thanks for the response.

That makes sense, and I understand what you're saying there.

But here's my problem with having another client on the management vlan: how do I access that client if I'm not physically in the office, and what happens when/if that client crashes or becomes inaccessible?

I guess what I'm looking for here is strategies other people use to accomplish all of the following:

* separate management vlan, for security purposes (as you mention above)

* ability for a remote admin (like me, from my home, at 10:30 at night) to access the routers remotely in case of problems (this implies that a remote admin has to be able to access that management vlan.  But, if it can be accessed, does it defeat the purpose? I feel like this is a catch 22, in a sense)

* not have to rely on a client being set up on the management vlan, becaue if that client crashes, you are out of luck

I guess I'm not looking for a specific answer here, since it seems like there could be many different strategies used, but can anyone give me examples of how they deal with this?

Now, I just want to say the following: I may not get the vlan-specific stuff (just starting learning it), but I have a solid understanding of non-vlan "standard" networking.  I can ssh into the server at my office from my house, or use vpn followed by a freenx connection to our linux server, so I can take care of getting into our office's network from my house, but give me some ideas on what I'd do from that point to access the management vlan in the office.

For example, should I set up a separate NIC in the server that has access to the management vlan?  Or use a console (serial) server, accessible from our server?  Or set up some custom routes that apply only to certain clients?

Again, I realize that there are probably many ways to approach this... just looking for some simple suggestions.  Heck, even if that suggestion is: "For a small enough company where you trust all your employees completely, and have a good firewall set up, just make the management vlan the data vlan".  (This would actually be my preference, for obvious reason :-)  )

Thanks again

[packettracer86 · Accepted solution]

Hello Scott,

my suggestion for your case:

Some of your Servers <--> FW <--> SSH Server <--> FW <--> Management Network

Set up a separate SSH (maybe also ftp and logging?!) Server that is only connected to your FW.

Allow the connection from your Servers (the one you already user remotely from home) to the FW and install a

Terminal Software or something like that on it.

Than make a simple rule which allows only a connection to your Management by the SSH Server, nothing else.

And while I am writing these lines, I think you should set up two SSH Server on two different physical machines, just in case ..... =D

[sbgoodwin]

Thanks for the advice!

I'll try setting something like this up in the near future.

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

What's typically done is control access to the device by authorized login and control physical traffic accepted by the device.  An example might be ACLs on the device (itself) controlling actual traffic accepted by the device and/or VTY ACLs.  (In other words, there might not be a dedicated management VLAN but the device does control what it accepts to itself, logically and perhaps also physically.  The management VLAN might also just be VLAN1 without any normal data traffic.)

If and/or additional control is also desired to the management LAN itself, device ACLs can be use to control traffic to/from the management VLAN.  Packettracer86's example of using a FW would be an extreme example as (other) device ACLs are often "good enough".  Another newer isolation technique is also using L3 segregation via VRFs.

Like many other network design issues, often one-size doesn't fit all.  Any security has a cost to implement and maintain, so you often try to balance that against perceived risk.  How secure a device ought to be depends on its exposure.  For example, extreme security probably isn't warranted for a typical internal business network, but such might be warranted for an Internet attached devices (or devices exposed to student access).