Wednesday, November 30, 2016

Introduction to Private VLANs

 on  with No comments 
In , ,  
Private VLANs are a technique used to restrict communication between hosts or group of hosts within a VLAN.  In other words, isolation of hosts and/or groups of hosts. These differ from Private VLAN Edge, which I have previously blogged about.  Private VLAN Edge is a much simpler topic, in theory and in practice, that is the only option on lower end switches such as the Catalyst 2950.   Private VLANs are more featureful, and by extension of that, a bit more complex to implement.

The need for Private VLANs can be imagined when thinking about the early days of cable modems and DSL.  Poorly configured ISPs allowed broadband customers to see one another on the Internet.  At the time, many customers did not have a router at home, they would just connect their PC directly to the cable modem.  In the interest of IP address conservation, ISPs would put entire neighborhoods (or even more) on to a single subnet and on a single VLAN, and this allowed directly connected PCs to see one another.  Network Neighborhood in Windows 98 found many of my neighbors back when I first signed up for Media One broadband.

In the ISP situation, what would their options be?  Subnet their address range down and give each customer a /30?  That would essentially lose 75% of their address space as a /30 would assign 4 IP addresses to each customer instead of 1.  Also note that they'd need a VLAN per customer, and switches are limited in the number of active VLANs that they support.  So they would need to limit the number of customers per switch, which would increase the number of switches necessary, as well as routers to connect those switches.  They could use VLAN ACLs or other advanced techniques, but that could get very complex very quickly, and may not scale well.

Also consider a co-location facility hosting web servers for a number different clients.  They want those servers to be reachable from the Internet, but most likely not reachable from each other.  This is especially true if one were to become infected with a fast spreading worm.  A client at the co-location facility may also have more than one server.  These servers may need to communicate to one another, and to the Internet, but not to other clients.  How does the colo handle this increasingly complex setup?  One possible solution is Private VLANs which allows granular separation of customers.

In the Private VLAN, there are two types of port assignments.  First is the Host port, which inherits its behavior from the Secondary VLAN type it is assigned to.  This is just your standard host.  A server, workstation, printer, etc.   Next is the Promiscuous port.  This port is able to communicate with any other port in the Private VLAN, even those in an isolated secondary VLAN.  Promiscuous ports are generally where you would have a router or a firewall rather than a workstation or server.

To use Private VLANs, you start with an overall container, which is known as the Primary VLAN.  Think of the Primary VLAN as you would the standard VLANs you know, but with additional features.  The Primary VLAN works pretty much like any other VLAN on the switch for the most part, with few caveats that I'll get to as they come up.

Inside of this Primary VLAN will be one or more Secondary VLANs.  There are two primary types of Secondary VLANs.  First is the Isolated VLAN.  This type of Secondary VLAN contains individual hosts that cannot communicate with each other or other secondary VLANs, but can communicate with promiscuous ports.  Second is the Community VLAN.  This type of Secondary VLAN contains hosts that can communicate with each other but not with hosts in other Secondary VLANs.  In Cisco-speak, the Primary VLAN forwards downstream from promiscuous ports to community and isolated ports.  The important takeaway is that Secondary VLANs can never communicate with other Secondary VLANs but can always communicate with promiscuous ports. Also note that these rules apply to all traffic: unicast, multicast and broadcast.  So keep this in mind if you need to use DHCP with an isolated secondary VLAN for example.

Private VLAN's can be trunked and span multiple switches as well. In this case, the secondary VLAN will be used to tag the frames as they travel the trunk.   Because of this, you may have to configure the Private VLAN settings manually on each switch. In Cisco switches, VTP3 has TLVs to carry Private VLAN information, but not all switches support VTP3. And VTP in any version is proprietary to Cisco, it's not supported in other manufacturers equipment.

In Cisco switches, they are supported on the Catalyst 3560 and higher, which includes the 3750, 4500 series and 6500 series switches, as well as other advanced platforms.  An interesting switch in this regard is the 3550.  With the right IOS, the commands for PVLANs are there, and you can enter them.  But there is some disagreement on exactly how far this gets you.  Cisco states for the record that PVLANs are not supported on the 3550, which many have taken to mean that you are free to use them, however Cisco will not provide you any technical support in that regard (or at least wouldn't when the 3550 was still a supported platform).  I've also seen it written in places (including a blog post by Wendell Odom if memory serves me correct) stating that while it will take the commands, and that they'll show up in the configuration, there will be no effect on the operation of the switch.  In other words, they are merely cosmetic.  As I have a 3550 switch in the lab and an assortment of IOS images to test out, I plan to visit this topic in the near future.  PVLANs are also supported by IOU L2 images should you not have access to real hardware.

Though Private VLANs are originally a Cisco developed concept, they are described in RFC 5517, Cisco Systems' Private VLANs.  It's supported by Arista, Brocade, Juniper, Netgear, and others.  They're also supported in virtual switches in Hyper-V (somewhat) and VMware.

If you don't have access to a Cisco switch or IOU L2 images to use, Arista vEOS images support PVLANs in a very Cisco-like manner.  In fact, most commands on Arista's vEOS virtual switch platform are very Cisco-like.  A friend of the CCNA group, Stuart Fordham has previously blogged about his experience with using Arista switches during his CCIE Security studies in a few posts.  At this point, IOU is available and it works well for most tasks, but Arista is an option at this point.  Arista vEOS can be found here.  It was downloadable with a free account the last time I checked, but that was a while back and YMMV.

In this post, I went over the basics of Private VLANs.  In future posts, I'll talk about configuring Private VLANs as well as investigating the commands on 3550 switches further.

Saturday, November 26, 2016

Registering ASP.NET for Office Web Apps Error

 on  with No comments 
In , ,  
Here's a quick and dirty post for something that came up recently in the lab.  I was setting up an Office Web Apps server, and was getting the following error:

Can't create new Office Web Apps farm: The server must be joined to a domain.

Seeing this error message was a bit frustrating to say the least, because the server was indeed joined to a domain.  After a bunch of searching with Google, I finally came across the answer.  While setting up the server, I had installed IIS before .NET, so I needed to register ASP.NET.  The required bits in IIS were already installed, so it was just a matter of registration. This can be done with the following steps:

  • Open an elevated command prompt or PowerShell console.
  • execute the command start Microsoft.NET
  • navigate to c:\windows\Microsoft.NET\Framework\v2.0.50727
  • execute the command asp_regiis.exe /i 
  • execute the command iisreset or restart the server
Other things to check for when getting this error are to ensure that your server really is connected to a domain (and that the server account in AD is not broken) and that you have the correct DNS Server specified in the network settings.

Wednesday, November 23, 2016

Windows 2000 on ESXi

 on  with No comments 
In , ,  
After my recent experience with running Windows 2000 on VirtualBox, I found myself wanting to build a Windows 2000 Workstation host on my ESXi server.  Just something quick and dirty to sit behind an ASAv so I could verify the ASAv's configuration.  Like always, the motivation was the low resource utilization of 2000.  The 64GB of RAM in the server has its limits.

I was able to install the OS just fine, and I figured that since it was an .iso with SP4 slipstreamed in, I'd be fine.  But when it came time to install the VMWare Tools, the installer stopped and complained "The Microsoft Runtime DLL installer failed to complete installation."  After a bit of Googling around, I found two possible solutions to this.

The first is the simplest of the two.  You can just grab the E1000 drivers from Intel and install them.  Putting the executable into a .iso file, and then mounting that on the VM is all it takes.  The downside is that you only get the network drivers, rather than everything installed by the VMWare Tools.  Everything else technically works, but you don't get the niceties such as the VM not capturing the mouse and keyboard.  Note that you'll have to scroll down the page and click "Show more" a few times before you'll finally find drivers that are compatible with Windows 2000.

The second of the two is to track down the necessary updates for Windows 2000.  This is a bit tricky as 2000 is no longer supported and none of the download links on the Microsoft website work any more.  Update Rollup for Windows 2000 SP4 (KB891861) has the fix you need. KB835732 is the patch that solves the issue, but you may as well install the entire update rollup if you can.

So where do you get the update rollup?  If you Google "KB891861 download" you'll find a few sites hosting a copy.  Since they're doing so in a less than legal manner, I'm not going to link any of them here.  If you can't find a copy online, your other option may be to install the Intel drivers to get connected to the network, then updating Windows 2000 from a WSUS server.

I've also seen it said that disabling the CD-ROM driver in Windows 2000 after copying the VMWare tools installer to the c:\ drive works as well, but I haven't tried that.

Saturday, November 19, 2016

Windows 2000 on Virtualbox 5.0.24_SUSE r108355

 on  with No comments 
In , ,  
I'm setting up a small GNS3 environment on my main workstations to test out a few thing.  I setup a couple of VMs, one for a domain controller, one for ACS 4.2.  Both VM's are running Windows 2000 Server because I can run it in a small amount of memory, and my workstation only has 12GB of RAM.  After installing the Base OS on both, I noticed a couple of issues.  For completeness, I'm running GNS3 1.4.6 on OpenSUSE Leap 42.1.  The OS is up to date with updates as of today, September 17, 2016.

First off, no matter which NIC I select, there is no networking.  Windows 2000 does not recognize the NIC despite the VirtualBox guest additions being installed.  I got around this problem by inserting the disc of an older version of the VirtualBox guest additions .iso (Version 2.0.4) that I saved a copy of for some reason in the past.  With this older disc inserted, I was able to search for and install the drivers for VirtualBox's AMD PCnet-FAST III NIC.  I've built Windows 2000 based VMs in the not so distant past (on some 4.x or 5.x version of VirtualBox), so this is a recent phenomenon.

The next problem is a big one as it caused me quite a headache getting the Guest Additions .iso mounted at all.  When attached to a GNS3 topology, the second you attempt to access the .iso file through Windows Explorer in the guest OS, the VM aborts.  Everything seems to be fine when the VM is not attached to GNS3.  The same thing happened with my Windows 10 VM, so I would imagine that this behavior exists regardless of the OS installed on the Guest.

A third thing to look out for is that Windows 2000 SP4 will not install on Windows Server 2000 Datacenter in a VirtualBox VM.  After it extracts the files, you get a message stating that "This Service Pack 4 has not been qualified by your hardware vendor for installation on this copy of Windows 2000 Datacenter Server."  Obviously not a VirtualBox problem, but something else to keep in mind.  Standard Server and Advanced Server don't have this problem.  I've found a registry hack for Server 2003, but nothing for 2000.

Saturday, November 12, 2016

SENSS Passed

 on  with No comments 
In ,  
Just a short post for this week, as I've done recently.  This exam has completely consumed my time lately.  Because I had yesterday off, I scheduled my second attempt at the SENSS and nailed it this time with a score of 910.  Exams are a lot easier when you know what you need to know, aren't they?  This isn't a knock against Cisco's exam topics, I just didn't have a good idea of just how deep I needed to know certain things that didn't seem like they'd be covered as heavily which lead me to spend a lot of time on things that weren't really covered very much.  It was my first failed Cisco exam, and quite a humbling experience. Either way now I have a much better idea idea of what I need to do moving forward in the CCNP Security.

Next up, I don't know yet.  I plan to take a couple days to recover from that experience and give some thought to which exam I want to tackle next.  While the SIMOS looks like it'll be a lot more fun as it's very heavy in cryptography and VPNs, the SISAS may be more practical as ISE reared it's head multiple times already in the SENSS, and I doubt it won't be in the other exams as well. Besides that, the SISAS is the only exam with a certification guide, so getting to see a little bit of structure in exam preparation may be of use.

Either way, it's not going to be the SITCS this time.  There's no way I'll be able to knock out v1.0 before December 16, and I'd prefer to wait a little bit and let the community hash out exactly what v1.5 is before attempting it.  There was a lot of butt-hurt early on for all 4 of these exams from the early attempts and I'd hate to join the ranks.

Also in the near future will be the CISSP, which is the capstone of my Masters Degree, and the Upgrading Your Skills to MCSA Windows Server 2016 exam.  I haven't decided when I'll mix those two in yet either.  So for now I'll just be kicking the tires on Server 2016 and starting to tinker with ISE.  I've got a few SENSS related posts still in very rough form, so I'll probably get those presentable and post them here and there as well.

Saturday, November 5, 2016


 on  with No comments 
In , ,  
Syslog is an industry standard protocol for the purpose of message logging. It was developed by Eric Allman, originally as part of the Sendmail project.  Because of it's utility, it was adopted by other applications and eventually became the defacto default logging system on Unix like systems.  It was eventually documented by RFC 3164 (The BSD syslog Protocol) and standardized by RFC 5424 (The Syslog Protocol).  Many other RFCs exist extending the basic functionality such as RFC 5425 (TLS Transport Mapping for Syslog).