Author Archives: Valerian Ceauș

Configuring Cisco ASA 8.4(2) on GNS3 1.3.13

In one of my previous post (link here) I did a description on how to configure and run an ASAv instance on GNS3 1.4.5. In this post I will describe the steps required to configure and run a Cisco ASA 8.4(2) image on GN3 1.3.13.

Why in this case I insisted to use the previous version suite 1.3.x of GNS3 (1.3.13 at the moment of this writing) instead of the latest available 1.4.x suite ? The answer is because for ASA 8.4(2) to run successful, a QEMU emulator of version 0.11.0 needs to be in place and functional or as it seems, the QEMU 0.11.0 categorically refuse to work in GNS3 1.4.x suite (even it is installed here). Somewhere in forums found that GNS team will no longer offer support for QEMU 0.11.0 in its product. Maybe in one of the future releases but certainly not now …

Someone might ask, why not just use the 2.4.0 version of QEMU present and functional in both GNS3 versions suites ? The truth is that it works, but with a little issue, a very slow speed through device interfaces. In my testings, a simple ASDM image copying can take several hours with a high chance for device crashing. Types and number of NICs, license or whatever else doesn’t change the situation.

So, because of unavailability of QEMU 0.11.0 in GNS3 1.4.x I switched back to 1.3.x version suite. Why then, I didn’t use the 1.3.x suite in my previous article for an ASAv instance configuration ? It is because we needed the VNC console for ASAv initial configuration or that is present only in newer 1.4.x suite.

To conclude: for ASAv you will need GNS3 1.4.x (because of VNC console) and respectively for ASA 8.4(2) you will need the GNS3 1.3.11 (because of QEMU 0.11.0). At least in my testings, this offer me a stable and workable setup.

Note0: do not mix the GNS3 1.3.13 and GNS3 1.4.x on the same machine, simply because they wasn’t designed to work together, configuration that most probably lead to complete nonfunctional setup.

Why bothering also with ASA in addition to ASAv ? Doesn’t ASAv being sufficient ?

Well, the ASAv is a software designed to run in virtual infrastructure and such that, some features are no longer needed here. Take simple, what ASA doing by clustering, in virtual infrastructure with ASAv is accomplished by hypervisor’s High Availability features, multiple contexts are replaced by multiple standalone ASAv instances and so on. To be more precise, that’s the unsupported features that that the official documentation (link here) states: The ASAv does not support the following features: clustering, multiple context mode, active/active failover, EtherChannels, Shared AnyConnect Premium Licenses.

So in case you want to play with ASA clustering or multiple context mode you will need a classic ASA instance running in GNS3. ASAv is good but not always sufficient. Even so, ASAv should be your standard, especially since it is somewhat closer to VIRL style.

What images are needed to run ASA in GNS3 ?

Compared to ASAv where an original qcow (KVM) image was sufficient to configure the device in GNS3, for ASA the original bin image are not sufficient. The truth is that this original image needs to be unpacked, then some files modifications needs to be done and after that repack the content in a way suitable for QEMU. All of this can be done manually or scripted (see GNS3 forums for Cisco Image Unpacker for Windows or shell script for Linux) but imho, if you not search for a specific ASA version just do a search on the Internet for ASA 8.4(2) GNS3 files. Other versions should be also be available to. In any case, you should be left with two files: asa-vmlinuz (a Linux kernel) and asa-initrd.gz (a RAM disk file). These are the files used by QEMU in GNS3.

How to configure Cisco ASA 8.4(2) in GNS3 1.3.13 ?

  1. Download the latest version for 1.3.x GNS3 version suite. To do that, go to GNS3 web site – avoid the download button witch will direct you only to GNS3 1.4.x download, instead, click on software  (top bar menu) – on the left, written with small font size, click on To download Version 1.3.13 of GNS3 Click Here (see screenshot below). After, authentication a download for GNS3-1.3.13-all-in-one.exe file should start.

art - configuring Cisco ASA 8.4(2) on GNS3 1.3.13 - download page

  1. Install the 1.3.13 GNS3. No rocket science here, just follow the installation wizard. Setup will install one by one all the components needed: Dynamips, QEMU, GNS3, WinPcap, Wireshark and many others parts.
  2. Initial GNS3 configuration. At this step, I usualy configure some general, non-essential, GNS3 preferences:

    1. General – Local paths – projects/binary images – redirected to a shorted path, e.g. C:\GNS3\projects and respectively C:\GNS3\images
    2. In Topology View change the default label text style to a less accentuated one.
    3. In Miscellaneous – disable the Automatically check for update and Automatically send crash reports options.
  3. Create a new Cisco ASA device by starting New QEMU VM template from Edit – Preferences – QEMU VMs – New menu. Use the following parameters:

    1. Type: ASA 8.4(2)
    2. Name: ASA5520-8.4(2) or any meaningful title you choose
    3. Qemu binary: leave the default qemu.exe (v0.11.0)
    4. RAM: 1024MB or more, 1024 is the minimum
    5. Initial RAM disk (initrd): select RAM disk file, e.g. asa8420-initrd.gz
    6. Kernel image (vmlinuz): select Kernel image file, e.g. asa842-vmlinuz

I will recommend to store original OS images in other folder than that used by GNS3 for image storage. When you specify an image to be used by GNS3 a copy of that original file would be automatically copied to GNS3 binary image folder location.

After device creation, edit VM configuration and add up to 6 network adapters (network section). Leave the rest parameters untouched.

art - configuring Cisco ASA 8.4(2) on GNS3 1.3.13 - ASA device summary settings

art - configuring Cisco ASA 8.4(2) on GNS3 1.3.13 - ASA device general settings    art - configuring Cisco ASA 8.4(2) on GNS3 1.3.13 - ASA device HDD

 art - configuring Cisco ASA 8.4(2) on GNS3 1.3.13 - ASA device network    art - configuring Cisco ASA 8.4(2) on GNS3 1.3.13 - ASA device advanced settings

Note1: The steps above was successfully tested inside a Virtual Machine with Windows Server 2012R2 as a guest OS. The VM was provisioned with 2x vCPU and 8GB RAM and run on an ESXi host. Physical server equipped with Intel Xeon E5320 1.86GHz CPU.

Note2: There is no need for: Expose hardware assisted virtualization to the guest OS …No VT-x needed inside the Virtual Machine.

Use the newly created ASA device template

Now, you can use the newly created ASA device template, just drag the device to the map pane, build the topology and start it. Open console, if everything is ok you should see a typical ASA OS loading progress. After a minute, you will be faced with long awaited Cisco ASA CLI (use empty password for privileged exec mode).

You can use as many Cisco ASA instances in your projects as you want, sure no more than your hardware permit. Every time you instantiate a new Cisco ASA device, a flash disk device is created and mounted automatically for each Cisco ASA instance thus no additional steps for virtual disk creation needed. You can find the qcow virtual disk file (flash.qcow2) associated to your ASA device in project folder/project-files/qemu/dev-uiid/ folder.

Usualy, the first step before using ASA is to put a license key. If you do a simple google search you will find several freely flying license keys. Just use one of them. For me, it turned out to be ok the following activation key: activation-key 0x7212d04a 0xe041d3fe 0x1d22f820 0xea5440e4 0x8231dd9f … which unlike other keys does not hung loading progress for several minutes after activation.

A curious case for FTP passive mode over NAT on Cisco IOS router

Recently, I came across an interesting feature on Cisco IOS that mysteriously do something similar to an application inspection for FTP protocol and more that that, make modifications into replay messages from FTP server. You know, a router is a Layer 3 device that has no rights to do payload modifications, in some cases at most just several fields in IP header (e.g. TTL, src/dst IP addresses and port numbers in case of NAT). The behavior observed by me looks like oposite: a Cisco IOS router, when configured to do NAT, make specific changes on some FTP control messages. It’s like a router had borrowed something from ASA firewall inspection features.

Let’s do now some testings. For our scenario I built the following simple topology in GNS3.

a curios case for FTP passive mode over NAT on Cisco IOS router - lab topolgy

The three components used are:

  • the FTP client is a Windows 7 VM running in VMware Workstation
  • the FTP Server is a Windows Server 2008R2 VM running in VMware Workstation
  • the R1 is a Cisco IOS 7200 router with Cisco IOS version 12.4(24)T5

Note0: In my testings I used the FileZila 0.9.56 as an FTP server and Total Commander of version 8.51a with his embedded FTP client.

Note1: FTP server run in Passive Mode. My focus was only for FTP passive mode simply because this is the use case I have in my production scenario. I will not talk about FTP active mode.

On Cisco router applied the following simple configuration (interface & static inside NAT conf):

After NAT, the FTP server is seen by the FTP client by IP address.

As you can observe an additional ACL that deny any un-NAT-ed communications is applied inside on FastEthernet0/0 (from FTP client side) – just to be sure that all sessions pass through NAT.

Now, I will start two packet capture sessions in Wireshark for both router’s interfaces and initiate a new FTP passive mode connection to FTP server.

In Passive Mode the client request Passive mode operation by issuing the PASV command over the control connection on TCP port 21. The server suggest a data port and IP address, to which the client must connect. The port number are somewhat encoded in several message fields, see the formula in the illustration below.

a curios case for FTP passive mode over NAT on Cisco IOS router - passive mode ilustration

The following screen show the capture of Passive mode acknowledge message (Passive OK, 227) packet with most important fields highlighted (src/dst ports, pasv response args).

a curios case for FTP passive mode over NAT on Cisco IOS router - packet capture at source_c

Where: 1-passive mode request, 2-passive mode acknowledge, 3-acknowledge message arguments, 4-passive IP address (server IP), 5-passive port (listener for data connection), 6-source port for data connection (ephemeral), 7-control connection server source port, 8-control connection server destination port (a value different from 6).

If we look now at the same packet but this time after it passed the router/NAT we would see, besides the destination IP change in IP header (because of NAT), also the FTP message payload modifications: specifically, in message arguments, values from 192,168,2,20 changed to 192,168,3,20. It is obviously an effect of NAT FTP protocol inspection and corresponding changes in message made by router.

a curios case for FTP passive mode over NAT on Cisco IOS router - packet capture at destination_b

A more in depth information about how this all works you can find here: – Routing TCP/IP, Volume II (CCIE Professional Development) – Network Address Translation (link here), btw, one the few sources available on the net.

What if the FTP server will be set to function on a non-standard port ?

The answer is that the inspection embedded in NAT would ignore such a server. It simply do just the standard NAT section but not also the payload inspection and modification. Ironically, that was the reason why, initially, I couldn’t understand why this works perfect in lab but not also in production. It appeared to be that the non-standard port applied on prod. FTP server was the culprit.

The next question then arise: What needs to be done for NAT FTP inspection work for non-standard FTP ports ?

More by accident than intentionally I found this cool Cisco article: – Using Non-Standard FTP Port Numbers with NAT (link here), that explain what to do – not so much, just two additional configurations. In my case these would be:

First, we create a standard ACL that would include the FTP server’s IP address (before NAT), and second, we would teach the IOS NAT to inspect on non-standard port number (in our case 5555) for that IP. If more than one FTP servers are used then add those to ACL too and if more than one tcp port numbers are used for control connections then specify those one by one separated by comma in second configuration command.

Bellow, you can see the ftp connection logs before (first section) and after (second section) the above configuration wad applied and FTP server configured to work with non-standard port number.

a curios case for FTP passive mode over NAT on Cisco IOS router - ftp client logs

As can be observed, after applying configuration, the FTP server answer message arrive already modified with NATed (global inside) server IP address in payload.

How to deliberately disable NAT inspection?

It can be done only per NAT entry (no global configuration), by specifying no-payload keyword at the end of NAT entry definition command.

Why is so important for IP addr. in pasv answer to be fixed to FTP server’s NATed (global inside) value?

Well, actually the importance depends on how FTP client are configured/build. The truth is that an FTP client can work either in restrictive or in less restrictive mode (can’t remember from where I got the terms, they may be wrong) and depending on that, ignore or not the value provided in pasv answer message. An FTP client configured for restrictive mode will try a data connection only to IP address suggested in pasv answer, if the de connection could not be established the FTP session will fail. At the oposite side, an FTP client in less restrictive mode would simply ignore the IP address suggested in pasv answer and would try instead the IP address used initially for data connection (the IP address that you configure in FTP client. Obviously, the global inside address).

So, if you have an FTP client configured/build for restrictive mode then is important to have NAT inspection doing IP address exchange in pasv answer message. Again, absolutely by accident, I found that older versions of Total Commander use the restrictive mode for their FTP client (7.04a in my particular case). It was an opportunity for a little test with such a client. Bellow, you can see the FTP client connection logs for (a) with NAT inspection and (b) without it and the final FTP session status. 

a curios case for FTP passive mode over NAT on Cisco IOS router - ftp client in restrictive mode

Clearly, for FTP session to succeed, a NAT FTP inspection that will do also translations in pasv answer message payload, needs to be in place.

How to setup Cisco ASDM in Demo mode

Today, I’ve encountered some issues during installing Cisco ASDM in Demo mode. In this post I will address this issues and show a step by step instruction on how to successfully setup ASDM for Demo mode.

In my attempts, I started by installing the lattest available versions for ASDM Demo (ASDM Demo 7.3.1) and Java JRE (Java 8 update 91) but finally got an unworkable setup. Every time trying to start demo mode a generic error that state that Demo software is not installed popping up (screen below).

How To setup ASDM demo mode - error mesage

Furthermore, if you go to application folder in Program Files (x86) you will see an empty ASDM\Demo folder, as like Demo mode not even installed.

After several attempts, I haven’t found a better solution than to downgrade my Java JRE (8u91) to the previous major release (lattest update): Java 7 update 72. Also, at least when you start setup process you must have a 32 bit version of Java installed.

To complete a Cisco ASDM setup in Demo mode:

  1. Download the lattest available Cisco ASDM Demo setup file. For this, go to Cisco download page at Products – Security – Firewalls – Firewall Management – Adaptive Security Device Manager – Adaptive Security Appliance (ASA) Device Manager and search through the ASDM versions available the latest one that have the word demo in setup (msi) file title. The release policy for ASDM demo don’t coincide with that for ASDM. At the moment of this writing the lattest available ASDM Demo was: ASDM Demo 7.3.1. For download to succeed you will need a service contract associated with your login, otherwise a simple googling will reveal a leaked image somewhere in Internet.
  2. Download the latest available Java JRE 7 release (Java 7 update 72), both for 32 and 64 bit with 32 bit being mandatory (setup files are jre-7u72-windows-i586.exe and respectively jre-7u72-windows-x64.exe). Install both versions, these will function perfect together.
  3. Launch ASDM Demo setup and go through a banal installation wizard. The ASDM Demo 7.3.1 setup will install also the ASDM-IDM Launcher of version 1.5(73) so if you have a newer Launcher already installed it will be overlapped. If you later try to connect with this older Launcher to an updated ASA ASDM you will prompt for Launcher update. To avoid this version swapping back and forward I will recommend to setup DEMO mode somewhere on another PC, perhaps on a Virtual Box/VMware Player VM.

Note0: The steps above was successfully tested in a Windows Server 2012R2 OS Virtual Machine.

Note1: For a guide on how to disable Java Update to proceed automatically you can read here.  Simple unchecking the Automatically Updates from Java Control Panel is not enough you will need edit specific registry key.

If everything succeeded, your ASDM\Demo folder in Program Files (x86) should be full with plenty of files:

How To setup ASDM demo mode - demo folder

Now, we can start using Cisco ASDM in DEMO mode: start ASDM Launcher (icon on your desktop) – check Run in Demo Mode:

How To setup ASDM demo mode - launcher for demo mode

Select the preferred configuration, and click OK, ASDM Demo mode should start. In the above screen note the Device IP Address/Name field automatically filled with a localhost address (not appear on first run).

How To setup ASDM demo mode - asdm demo started

Now, you can start gamming with an imaginary topology with configured ASA devices.


How to configure ASA for ASDM access

It this short post I will go through the steps of configuring ASDM access on an ASA device. I will use the ASAv 9.5.2 appliance just configured for GNS3 in previous post.

Copy the ASDM image to ASAv appliance

First, we need to copy a compatible ASDM image to ASAv internal storage. Therefor:

  1. Go to Cisco Download Software portal at Products > Security > Firewalls > Firewall Management > Adaptive Security Device Manager and download a compatible ASDM image for your ASA device. For download to success you will need a service contract associated with your profile otherwise try a simple Internet search for a leaked image. Verify compatibility by consulting the Cisco ASA compatibility (link) article. For my ASAv version 9.5.2 an ASDM version will compatible and sufficient.
  1. In GNS3, build a simple topology that will connect ASAv to some external network. To do that, connect one interface from ASAv to a cloud object configured to be linked to one of the host interface – for this purpose I usualy use a simple loopback adapter (for how to install such a one, read this technet article. reboot required). Because the ASA can’t connect directly to a cloud object a transit synthetic switch needs to be added. At this step, your topology should look like this:

How To configure ASA for ASDM access - topology view

Note0: Ethernet0 on ASA as presented by GNS3 correspond to Mangement0/0 intf seen from inside the device.

Note1: For a better look, changed the symbol/hostname used for cloud representation.

  1. On host computer start your favorite TFTP daemon (for this purpose I use tftpd32 from Configure the daemon directory and listening interface, additionally verify you host firewall to allow tftp protocol.

How To configure ASA for ASDM access - tftpd32 config

  1. Start the ASAv device and open the serial console. Configure interface IP settings, verify connectivity and copy the ASDM image to ASAv internal storage:

How To configure ASA for ASDM access - intf. configuration

A copy process should now begin. The progress seems to be less rapid than expected (in my case a top was the 60kbps) which could be because of unlicensed state of ASAv. In essence not a big problem, just wait for 3-5 minute for operation to complete. For confirmation do a dir command:

How To configure ASA for ASDM access - dir flash

Configure ASAv for ASDM access

Now it’s time to configure ASAv for ASDM access. Execute the following commands:

First two lines configure authentication, in this particular case against the local user database, second group of two commands enable HTTPS server and access from network via mgmt interface (Management0/0) an the last command tell the firewall to use asdm-752-153.bin image for ASDM access.

Next, switch to your browser and try to open https for management interface If everything is ok, a security certificate error should appear in your browser, confirm the certificate exception to go forward. You should see a page like this:

How To configure ASA for ASDM access - ASDM welcome page

From this point you have two options: (a) via Java Plugins or (b) through ASDM Launcher. My preference is to use the ASDM Launcher. First install the ASDM Launcher – after click Install ASDM Launcher and successfully authentication a setup file will be made available for download, second start ASDM Launcher (icon on your desktop should be already present).

In ASDM Launcher authentication window, put the ASAv IP address and the authentication credentials.

How To configure ASA for ASDM access - ASDM launcher

Finally, after loading ASAv configuration, ASDM application should start:

How To configure ASA for ASDM access - ASDM view

Configuring Cisco ASAv 9.x on GNS3 1.4.x

Recently I went through an interesting experience of Cisco ASA setup in GNS3. I must say it was a real challenge, but finally, not an impossible task. There is a lot of particularities you must take into account, all depending from ASA version to GNS3 release. In this post, I will focus on how to configure an ASAv firewall to run as a QEMU VM in new GNS3 version suite 1.4.x. As of date of this writing I was able to access ASAv image version 9.5(2.204) and the GNS3 1.4.5 setup.

The 1.4.x suite of GNS3 is a relatively new appearing into the scene, and how is typical with new software releases, surely expected to have some bugs and/or incompatibilities. That’s why my first attempts was made in previous software suite of 1.3.x version (actually 1.3.13 version). It was a wrong way, because how I realized soon, for ASAv to be configured, a VNC console should be attached, or in 1.3.13 I didn’t found how to do that (is not excluded that I missed something). As a consequence, I quickly switched to newest GNS3 1.4.5 version. The following text assume a newly setup of GNS3 version 1.4.5 with no additional settings, except maybe only for the default location for project and binary images folder – I prefer to reconfigure these on C:\GNS3\Projects and respectively C:\GNS3\Images.

Cisco ASA virtual appliance (ASAv)

Cisco ASAv is a re-imaged version of Cisco ASA specifically designed to run as a VM on top of some hypervisor. In fact, the same ASA code is running, but in different form factor. There are versions for vSphere, Hyper-V and KVM. Just because GNS3 use QEMU as a VM emulator we will employ the KVM image of ASAv. By the way, ASAv is the image Cisco use in their notable virtual labs VIRL. Not all ASA versions are available in a VM format – I suppose only those starting with 9.x, thereby if you want to try some older versions, e.g. popular ASA 8.4(2), you will need to experience another approach (a new article devoted to this subject should come). It’s worth noting that the ASAv have some limitations compared to classical ASA, in particular you wouldn’t be able to build firewall clusters (failover or A/A), test multiple context mode feature or play with Etherchannel. For this scenarios, I usualy use an 8.4(2) ASA setup – which, by the way should run only in QEMU 0.11.0 which in turn can’t be started in GNS 1.4.x, only in previous suite 1.3.x !!!.

So, before we start we need to obtain somewhat the ASAv image. If you are fortunate enough to have access to Cisco downloads (a service contract associated with your profile is needed) then just go to – All downloads – Products – Security – Firewalls – Adaptive Security Appliances (ASA) – Adaptive Security Virtual Appliance (ASAv) and download the qcow2 (KVM) image of ASAv for your preferred version.

configuring Cisco ASAv 9.x on GNS3 1.4.x - download page for Cisco ASAv

In case you do not have access to official Cisco downloads, yet I recommend to try a simple Internet search, good chances are to find somewhere a leaked image (usualy on some China resources). To be honest, I can’t understand why Cisco restrict downloads to this type of software, anyway, next after setup you will need a license key to go over the limitations of unlicensed state of appliance (bandwith limitation to 100kbps). It would be fine if Cisco would allow download and free use of appliance in unlicensed state, respectively for production usage a suitable license should be bought.

Configuring ASAv template on GNS3

A step by step guide follow:

  1. Start new QEMU VM Template wizard with following parameters:

    1. Type: Default
    2. Name: ASAv-8.5(2.204) or any meaningful title
    3. Qemu binary: qemu-system-x86_64w.exe (v2.4.0)
    4. RAM: 2048 MB
    5. Disk Image (hda): C:\GNS3\images\QEMU\asav952-204.qcow2

Note: I will recommend to store original OS images in other folder than that used by GNS3 for image storage. When you specify an image to be used by GNS3 a copy of that original file would be automatically copied to GNS3 binary image folder location.

  1. Edit newly created QEMU Template:

    1. General settings – Symbol :/symbols/asa.svg
    2. General settings – Category: Security Devices
    3. General settings – Console Type: VNC

Note0: in my testing, I tried to change vCPUs from 1 to 4, but nothing more than 1514 Illegal Instruction (core dumped) … error message got in ASAv, hence don’t touch that value, we will set the number of vCPUs in other place for ASAv to be an SMP virtual machine.

Note1: Switching the console to VNC type one it’s like directly connect with a keyboard and a monitor to the virtual machine. Initial ASAv configuration don’t allow access to the serial console port so at least at this stage, the only possible option is VNC. Don’t forget, the ASAv was designed to play in a VM with a full console. Even so, we will configure serial console port to ASAv as well.

  1. Network – Adapters: 6x (default e1000 type)
  2. Advanced Settings – Additional settings – Options: -cpu Haswell -smp 4,sockets=4,cores=1,threads=1

Note0: I successful used this string for all my Intel CPU. The microarchitecture (Haswell, Nehalem and so on) seems to no matter – successfully ran on different CPU generation with no problems. For AMD CPUs, community recommend to use (haven’t tested): -cpu Opteron_G5 -smp 4,sockets=4,cores=1,threads=1

Note1: the default option’s value: –nographic, should be cleared. This will be guarantee an automatic VNC console opening (for non-linked mode VM operation).

  1. (Optional) Activate CPU throttling – Percentage of CPU allowed: 80%
  2. Advanced Settings – uncheck: Use as a linked base VM.

configuring Cisco ASAv 9.x on GNS3 1.4.x - qemu ASAv template - summary

configuring Cisco ASAv 9.x on GNS3 1.4.x - qemu ASAv template - general settings    configuring Cisco ASAv 9.x on GNS3 1.4.x - qemu ASAv template - hdd

configuring Cisco ASAv 9.x on GNS3 1.4.x - qemu ASAv template - network    configuring Cisco ASAv 9.x on GNS3 1.4.x - qemu ASAv template - advanced settings

I think I will provide some additional inputs about the setting named: Use as a linked base VM. By default, QEMU VMs works as a linked VM which means that every time you create a new QEMU VM (in our case ASAv) in your project, a linked virtual disk is created to the original qcow2 image. All the modifications are thus recorded in that new file but yet unmodified block are read from original image. Through this, we can create hundreds of new QEMU VMs without needing to clone the virtual disk (that’s the similar to the technology used in VDI). Given the fact that during the life of an ASAv VM, disk modifications are really very few, results that the disk overhead created by each new ASAv are truly negligible. If you disable linked VM mode (uncheck the: Use as a linked base VM) the QEMU VM will interact directly with original qcow2 virtual disk (all writes will be recorded here). As a consequence a single QEMU VMs from this template can be started (just try to drag and drop a second ASAv to workspace and you will see an error message).

Why then we intentionally disabled linked base VM mode? First off, we need this only during ASAv template making and after this we will switch back to linked mode. Our interest is to do a series of configuration changes (first boot, serial console, ASDM image upload) in the original image file which we want to keep in all new ASAv instances created from this template.

Surely, the same results can be achieved by making the template in linked mode (linked qcow2 virtual disk) and then committing all the changes to the original qcow2 image via qemu-img.exe tool, but, I think it is harder. Just disabling and then re-enabling the VM’s linked mode settings seems to be much easier … the choice is yours.

To check the virtual disk that is mounted to QEMU VM just drag a new ASAv to an empty project, right click ASAv device – and choose show in file manager. An explorer window to qcow2 image opens – with linked mode disabled this would be the template image asav952-204.qcow2 located in binary image folder, whereas for linked mode this would be a qcow2 image (somewhere in project’s folder) linked to the original template – base virtual disk image. Also, additionaly you can check what qcow2 images are involved via Windows resource monitor – CPU – Associated Handles – filter by QEMU string.

  1. Drag a new instance of ASAv 9.5(2.204) to the working space on an empty project in GNS3. No topology are needed to continue, just single, unconnected ASAv device.
  2. Power-ON newly instantiated ASAv device (right-click – start) and immediately open the console (right-click – console).  In opened VNC terminal a loading progress (Linux) can pe observed.
  3. On Boot Loader phase choose the option: bootflash:/asa952-204-smp-k8.bin with no configuration load (anyway no configuration yet exists).

configuring Cisco ASAv 9.x on GNS3 1.4.x - bootloader

  1. In the meantime, it would be interesting to do some analyzing in Resource Monitor. First, to confirm the SMP nature of started QEMU VM look at the number of threads/CPU associated with qemu-system-x86_64w.exe process (CPU – Processes) – should be more than 4x thread/CPU in use, and second, to confirm the non-Linked mode of operation for the ASAv VM do a search in Associated Handles for a qemu key (CPU-Associated Handles) – in non-Linked mode, the VM should interact directly with the original qcow2 image: asav952-204.qcow2 (a screen is inserted below).

screen resource monitor - qemu treads plus handler not linked mode - 2

At the command prompt the number of vCPU can be checked by the show cpu usage commmad:

ciscoasa# sh cpu usage
CPU utilization for 5 seconds = 1%; 1 minute: 1%; 5 minutes: 0%

Virtual platform CPU resources
Number of vCPUs              :     4
Number of allowed vCPUs      :     0
vCPU Status                  :  Noncompliant: Over-provisioned

  1. If you carefully track the booting progress you will see that the appliance will discover that it starts for the first time (Initial bootup detected …) and for the system variables to be applied an automatic reboot will come.  So first time booting will end up with an automatic reboot. On the second boot, also choose the option with no configuration load in Bootloader Dialog. First and second time booting could take some time to progress so be patient and wait them to complete – sometimes it may seem that the appliance hung, try to wait several minutes before doing a forced powering off.
  2. If everything goes smoothly, after the second boot, you should reach the traditional Cisco command line prompter (empty password for privileged mode). At this stage, we will enable the serial console for the appliance. By default, the ASAv works only with traditional VM console (monitor/keyboard directly connected to x86 hardware) and additional steps needed to enable console via serial ports. More about that you can read here ASAv Quick Start Guide, 9.5, section Configure a Network Serial Console Port.

For serial console to be on, a file named use_ttyS0 should exist in root of disk0. It doesn’t matter the content, just to be present. The simplest mode to create such a file is to make a copy of an existing file – the documentation suggest to clone from coredump.cfg file, like shown below:

ciscoasa(config)# cd coredumpinfo

ciscoasa(config)# copy coredump.cfg disk0:/use_ttyS0

  1. Theoretically, here, we can do also some additional configurations, one that we want to keep in all the ASAv instances derived from this template. For example, we can copy here the ASDM image to disk0 to not be bothered with that in the future. Anyway, I will skip this step.
  2. Reload de appliance (type reload in privileged mode). You will see that the command prompt can’t anymore be accessed via de VNC console. I mean, the console will open, but, at one moment the interaction will be handover to the serial console and no more activity going to be possible by VNC. The last message recorded in VNC confirm that: Lina to use serial port /dev/ttyS0 for console IO.

configuring Cisco ASAv 9.x on GNS3 1.4.x - qemu ASAv template - console handover

  1. Now, after all the modifications to the ASAv image, we can switch the template back to his original Linked mode of operation. Also, we will switch the console settings to telnet type. Do the configuration changes in template settings, not in ASAv instance. The ASAv device from our temporary project can be safety removed, it has already done his job.

Using newly created ASAv template

To use the newly created ASAv template, just drag the template icon to the workspace, do your connections and power-on the device. You can use multiple ASAv devices running simultaneous with no problem, on my PC (i7-4970s CPU with12GB RAM) I ran five concurrent instances, all started ok and became usable shortly (less than 1 min).

Just because we don’t mention –nographic in template’s Advanced Settings – Additional Settings the VNC console will automatically open every time you start the device. If you close that window, the appliance will power-off automatically. The VNC console don’t interfere with serial console which you can open via context menu. If you add the -nographic option, the VM will start silent without a VNC console. Anyway, my preference is to leave the VNC console to open automatically, at least for the begging, just to have an additional visibility of the process.

After you load the ASAv device, you will periodically be announced by a missing license warning message: Warning: ASAv platform license state is Unlicensed … It is because the appliance don’t have a license key applied and it works in unlicensed state. As mentioned above, for lab and test scenarios, an unlicensed state are more than sufficient. In this state, you will get all the ASAv features but at the same time be limited to 100 Kbps interface bandwith.

It is interesting to see what virtual disks files are involved for an ASAv device started from our completed template. Beacause the template was configured as a Linked Mode VM, a linked virtual disk plus the base disk should be used, a fact confirmet by the screen below: 

configuring Cisco ASAv 9.x on GNS3 1.4.x - qemu ASAv template - linked mode virtual disks

To complete the story,  bellow I insterted a screencast for the process described above (youtube link). Enjoy.

VMware NSX logical routing LAB

Following the subject of previous post, I will continue with NSX routing LAB topology used by me in my NSX learning. LAB topology diagram are inserted below. 

VMware NSX logical routing LAB diagram

(click on picture for hi resolution image)

A brief description for lab topology:

  • There are tree VXLAN logical switches: 5001, 5002 and 5003 corresponding to segments in a formal three-tier application (WEB/APP/DB). Each segment have a related subnet network: for LS5003 (WEB), for LS5002 (APP) and for LS5001 (DB).
  • Inter VXLAN routing are provided by a Distributed Logical Router (DLR) and an Edge Services Gateway (ESG). DLR act as a default gateway for DB and APP segments and ESG provide routing for WEB network segment. First IP from each subnet are reserved for default gateway.
  • Both DLR and ESG are configured in HA configuration mode (active-standby) – that is why these services are represented by two VMs each (vShield Edge for ESG and Control VM for DLR) – x per Edge ESXi host.
  • A group of two ESG appliances configured for Equal Cost Multi Path (ECMP) routing provides upstream communications. ECMP are enabled as well for DLR and ESG routers.
  • All routers are interconnected trough a transit logical switch 5004. Routers in this segment will use IP addresses from subnet: .5 for ESG, .254 and .253 for each of upstream routers. The DLR router use two IP addresses: first (.2) as a forwarding address and second (.3) as a control plane address (protocol address).
  • DLR, ESG and upstream routers exchange routing information via OSPF. All routers forms OSPF neighbor relationships.
  • ESG router are configured with both interfaces (internal and uplink) as part of the OSPF process (mapped to OSPF Area 0). DLR router have OSPF activated only on uplink interface and configured to redistribute in OSPF directly connected networks (APP and DB).
  • Upstream routers use OSPF on its internal interfaces and form BGP peering with external physical routers via its uplink interfaces.
  • External communications take place trough a dedicated dvPG (EDGE) with uplinks via physical NICs – DirectPath IO pass-through from physical host to EDGE nested ESXi.
  • Upstream ESG routers will redistribute BGP routes in OSPF and conversely OSPF to BGP.  

Presented below, are the configurations applied on physical routers (RTR1/2). VLAN 100 are used to interconnect with ESG upstream routers (EDGE/ subnet) and VLAN 102 to reach next hop on Mikrotik router (subnet For Internet access, a NAT overload function is configured on Mikrotik network appliance.

VMware NSX logical routing - physical router configuration

After all the configurations applied, we can check the routing protocol adjacencies and routing table information. For instance, here’s what DLR routers showing us:

OSPF adjacencies with ESG router (.5) and upstream routers (.253 and .254)

VMware NSX logical routing - DLR ospf adjacencies

Respectively, the routing table: 

VMware NSX logical routing - DLR routing table

We can observe two routes learned via OSPF: one to (WEB) learned from ESG routers (.5) and a default route as external redistribute route. All other routers are directly connected type. Btw, is the IP address of the DLR’s router management interface and are the automatically assigned network used for heartbeating between DLR router failover peers.

BGP peering can be checked on one of the upstream ESG router:

VMware NSX logical routing - upstream ESG BGP peering

and corresponding, all known networks: 

VMware NSX logical routing - upstream ESG known networks

It’s interesting to verify the routes installed in routing table on physical routers. Bellow, are shown the routes on RTR1 physical routers.

VMware NSX logical routing - physical router routing table

Finally, we can check the connectivity to some internet resources from one of the VM connected to internal logical switch (5002/APP): 

VMware NSX logical routing - traceroute test

My NSX Lab environment – short description

In this post, I will insert a diagram from my NSX LAB environment. A brief description follow thereafter.

My NSX Lab environment – short description

(click on picture for hi resolution image)

General LAB environment description:

  • All NSX lab components (ESXi servers with NSX loadable modules, NSX manager, Controller Cluster VMs, DLR control VM, etc.) are performed as virtual machines, all running on a single physical server. It is the same physical server used by our students (at DNT) in their lab exercises. Physical server have sufficient capacity to support all of my NSX lab scenarios (in my particular case I had access to 8x 2,9GHz x5570 CPU cores, 64GB RAM, 500GB storage space on 8xHDD 10k RAID10 LUN).
  • Physical server resources are controlled by LAB vCenter Server that define a particular vAPP container with minimum reserved resources for each student. My NSX LAB act in such a container. Each student have privileges to manage VMs only in their own container.
  • All LAB scenario’s VMs can be connected only to one permitted port group: dvPortGroup-Students. This port group have no uplinks (in other words isolated from physical networks), configured to carry all VLAN numbers and act in promiscuous mode (mandatory for nested ESXi). Students will use a remote access VPN connection to get into this network (via a VPN gateway build as a VM connected at the same time to production and isolated students network). An http proxy server are configured to enable access to Internet http/s resources from isolated student network. Lab vCenter Server, VPN and Proxy Server are all part of ADM-INFRA-VMW vAPP container with restricted access.

Note: For more information about DNT classroom VMware’s lab environment check one of the previous article series (Mediu de laborator pentru studenții claselor de VMware, part I, part II, part III).

NSX lab architecture brief description:

  • NSX lab will use IP addresses from subnet (all IP allocations are shown in diagram)
  • a dedicated vCenter sever is installed (further integrated with NSX manager)
  • five nested ESXi are installed and configured. These are grouped in three clusters: two computer clusters and one edge/mgmt cluster.
  • two distributed switches are used, one for ESXi in compute clusters and other for edge/mgmt cluster. A single transport zone are configured across all ESXi clusters.
  • several VXLAN switches are configured and interconnected via a Distributed Logical Router or NSX Edge. Some test VMs are connected to these VXLAN switches.
  • EDGE cluster’s nested ESXi hosts are additionally equipped with dual port physical NIC brought here via DirectPath IO from physical server. Physical ports are connected to external routers and switches (Cisco equipment from our CCNP lab kit). 

Image below show the inventory views for LAB vCenter Server (left) and NSX LAB vCenter Server (right):

My NSX Lab environment – short description - inventory views

My list for useful links for VMware NSX studying

Recently, I had the chance to get a new VMware certification: VMware Certified Professional 6 – Network Virtualization. During the study, I made a list of useful links and references – a list that I want to share in this post. Certainly, the subject is continuously evolving so the list will become outdated shortly, but even so, it can be a starting point. The list is as is for the end of 2015, no updates will be added. The list is presented with no particular order.

  1. VMware NSX for vSphere (NSX-V) Network Virtualization Design Guide (pdf, 93 pag.) (link)
  2. VCP Network Virtualization – Exam Blue Print (pdf, 25 pag.)
  3. VMware NSX Install. Configure, Manage [6.0] – student guide (pdf, 480 pag.)
  4. VMware NSX Install. Configure, Manage [6.0] – lab manual (pdf, 226 pag.)
  5. – microsegmentation using NSX distributed firewall (pdf, 30 pag.)
  6. – NSX for vSphere, getting started guide (pdf, 43 pag.)
  7. – NSX for Newbies – Part 1-10 (link)
  8. – NSX Distributed Logical Router Deep Dive (link)
  9. – NSX Distributed Firewall Deep Dive (link)
  10. HOL-SDC-1403   VMware NSX Introduction (link)
  11. HOL-SDC-1425   VMware NSX Advanced (link)
  12.  – NSX – (link)
  13. buildVirtual – VCP-NV Objectives Study Guide (link)
  14. YAVB – Rich Dowling  – VCP-NV (link)
  15. Ivan Pepelnjak – Overlay Virtual Networks in SDN (pdf, 278 pag.)
  16. HOL-PRT-1462   Palo Alto Networks – Virtualized Data Center Security (link)
  17. HOL-SDC-1415   IT Outcomes – Security Controls Native to Infrastructure (link)
  18. HOL-SDC-1420   OpenStack with VMware vSphere and NSX (link)
  19. HOL-SDC-1424   VMware NSX and the vRealize Suite (link)
  20. HOL-SDC-1412   IT Outcomes – Data Center Virtualization and Standardization (link)
  21. HOL-SDC-1319  VMware NSX … (link)
  22. packetmischief – DCI: THE NEED FOR STRETCHED LAYER 2 (link)
  23. packetmischief – Five Functional Facts about VXLAN (link)
  25. packetmischief – DCI SERIES: OVERLAY TRANSPORT VIRTUALIZATION (link) // offtop
  26. packetmischief – FIVE FUNCTIONAL FACTS ABOUT OTV (link) // offtop
  27. telecomoccasionally – NSX for vSphere: Understanding Transport Zone scoping (link)
  28. VMware NSX Use Case – Simplifying Disaster Recovery – Part 1 (link)
  29. VMware NSX Use Case – Simplifying Disaster Recovery – Part 2 (link)
  30. Considerations for Management Interface of Distributed Logical Router Control VM (2122060)
  31. – Does uRPF Make Sense in Internet Service Provider Networks? (link)
  32. NSX 6.2 admin guide – Add a Logical (Distributed) Router (link)
  33. – Getting Started with VMware NSX Part I – Building Virtual Networks (link)
  34. – Getting Started with VMware NSX Part II – Building Virtual Networks (link)
  35. NSX Compendium- VMware NSX for vSphere (link)
  36. Сетевые оверлейные технологии для ЦОД. Часть 1 (link)
  37. Сетевые оверлейные технологии для ЦОД. Часть 2 (link)
  38. Сетевые оверлейные технологии для ЦОД. Часть 3 (link)
  39. Going Over the Edge with your VMware NSX and Cisco Nexus (link)
  40. The vSwitch ILLUSION and DMZ virtualization (link) // offtop
  41. Distributed virtual and physical routing in VMware NSX for vSphere (link)
  42. On choosing VMware NSX or Cisco AICI (link)
  43. What is Network Virtualization? (link)
  44. What is a Distributed Firewall? (link)
  45. An introduction to Zero Trust virtualization-centric security (link)
  48. VMworld 2014: SEC1746 – NSX Distributed Firewall Deep Dive (link)
  49. telecomoccasionally – Distributed Firewall (DFW) in NSX for vSphere, and “Applied To:” (link)
  50. telecomoccasionally – NSX for vSphere: VXLAN Control Plane modes explained (link)
  51. – Validating Distributed Firewall rulesets in NSX (link)
  52. – Implementing a  Zero Trust Security Architecture (link)
  53. Manage and report on a Distributed Firewall using NSX Manager and ESXi CLI commands (link)
  55. – VMware vCloud Hybrid Service Direct Connect Primer (link)
  56. habr – Сети для самых маленьких. Часть восьмая. BGP и IP SLA (link)
  57. VMware NSX, Convergence, and Reforming Operational Visibility for the SDDC (link)
  58. Tom Fojta's Blog  – vCloud Director with NSX: Edge Cluster (link)
  59. – vCloud Architecture Toolkit – vCAT-SP (link)
  60. – Border Gateway Protocol (BGP) with Windows Server 2012 R2 (link)
  61. – Multi-tenant Site-to-Site (S2S) VPN GW  with Windows Server 2012 R2 (link)
  62. NSX Use Case Diagrams (link)
  63. VMware vRealize Automation with NSX (link)
  64. Architecture Design: vSphere with IPv6 (link)
  65. Network Virtualization (NSX) and vSphere Data Protection Interop (link)
  66. VMware NSX Installation Part 5 – Checking NSX Controller Status (link)
  67. – Troubleshooting NSX-V Controller (link)
  68. – NSX Load Balancing (link)
  69. – NSX-V Edge NAT (link)
  70. – Useful VXLAN commands in ESXCLI 5.1 (link)
  71. – Understanding and troubleshooting NSX for vSphere 6.x DFW (link
  72. SR-IOV support status FAQ (2038739) (link)
  73. NSX vSphere troubleshooting (link)
  74. LAG vs. LBT for vSwitch Uplinks in vSphere  (link)
  75. vSphere Distributed Switch Part 14 – Configuring dvPortGroup General Settings (link)
  76. IPv6 in vSphere 6 (link)
  77. – The Inside and Outside of NAT (link)
  78. NSX Useful numbers – VCP-NV Study (link)
  79. Deploying, Troubleshooting, and Monitoring VMware NSX Distributed Firewall (link)
  81. Proxy ARP & ICMP Redirect in vShield Edge NIC – Explained (link)
  82. How to install and configure VMware NSX 6.1.2 SSL VPN-Plus Step by Step (link)

Following the subject, next I will post some info about my NSX lab environment.


What can happen if unexpected switch is inserted into network ?

It’s interesting to notice how one of the most used protocol in LANs STP (Spanning Tree Protocol) is so weak from a security standpoint. What I want today is to put a simple test scenario build in a Packet Tracer lab that illustrate what can happen if by mistake (or by an informed hacker) and some specific switch configuration a new switch is introduced into an existing network. Let assume the network topology illustrated in picture below (a screen taken from a running simulation in Packet Tracer apps). As can be seen, the topology is based on Cisco’s layered model with dedicated switches for network core and distribution/access (actually a particular case with distribution and access layers collapsed in a single one). Usually, switches used in core are more powerful in term of performance than other – these should have sufficient capacity to switch all aggregated traffic between network modules interconnected by core (in our simple topology the network core connect user’s access switch with data center distribution/access module). The network is fully redundant and protected from single-point-of-failure – there are redundant paths as well as spare switches. As a result of redundancy the network topology inevitably forms physical loops, which without a proper handling are translated in a logical loops. As is known, logical loops ca be detrimental for network performance and operations (if not completely destructive). In such a condition, once caught, a broadcast frame will spin endless in closed loop, more, they will tend to accumulate and form what is known as a broadcast storm (in typical size network is a matter of seconds, even just by ARP requests). As a result of storm, broadcast traffic will eat precious switch/link bandwidth resources leaving less (or nothing) for legitimate traffic. Above that, other negative effects of loops are: MAC address table entries flapping, occurrence of duplicate unicast frames, flooding connected end-nodes with looped broadcast and others. 

What can happen if unexpected switch is inserted to network-networkdiagram

The role of STP protocol is to prevent logical loops creations by ensuring one logical path in a network with multiple physical paths. The STP protocol will intentionally block all off the redundant paths that could cause a loop and in case of active path failure will dynamically react by re-activating (put in forwarding state) of some previously blocked paths. The STP is a distributed protocol, which run on all switches and that use a special format frames named BPDU (Bridge Protocol Data Units) for inter-switch coordination. The logic of STP is based on following two steps: (a) a root bridge (master switch) election and (b) a spanning tree algorithm (STA) running in determination what paths should be open for forwarding and what should be left blocked. Election of Root Bridge take place by comparing bridge priority together with switch MAC address of each switch involved in a specific STP instance (values are exchanged by BPDU messages). The switch with lower value Priority/MAC will win the election. The bridge priority, is a configurable parameter and by default has the value of 32768 on all switches, if not changed in advance the only factor that influence the root bridge election remain switch MAC address. Usually, an administrator will involve and change bridge priority in such a way that a specific switch can be designated as a Root Bridge – normally one of the core switches (more on why those will come). In second stage, the STA on every switch will calculate the cost of each logical path to the root bridge, select the path with least cost and use that path for traffic forwarding, other paths that do not form a best way to Root Bridge for other switches are left in blocking state. Path costs are calculated as a sum port cost consecutive to the root bridge. Port costs is based on values predefined by IEEE standard for each possible Ethernet bandwidth (e.g. 100Mbps have a port cost of 19, 1GbE cost of 4, lower speed higher cost).

In our topology, we can already observe the results of STP protocol actions: some links are active (ports on both ends are in forwarding state, shown by green circle) and some other links are blocked (one port at one of the end of link are leaved in blocked state shown by orange color circle). In that state, there are no any of L2 logical loops. Let’s try to explain how STP did that. If briefly:

  • One of the core switches (in picture from left) are designated as a Root Bridge. That was done by setting a lower (245776) bridge priority than the default value of 32768. Without that, Root Bridge can become any of switches from the topology (actually that with lower switch MAC address table). For backup purposes, the other core switch is configured with a bridge priority (28672) greater than first switch but lower than default value. In case of primary core switch failure the second core switch will gain (trough STP election) the Root Bridge role. The Root Bridge role assignment and configured bridge priority value can be checked from the output of show spanning-tree privileged mode command (see picture below, show command on SW1).
  • Every switch in topology will calculate the cost of every path leading to the Root Bridge switch and choose the least cost one as a forwarding path. It can be seen by one active path from every switch to root bridge (e.g. for SW3 F0/2 to F0/2 on SW1). Not for this topology, but in case of multiple paths with the same cost the STP algorithm will choose the path that begin with a port whose port_priority/port_ID is lower. The path cost can be viewed from the output of show spanning-tree command (in picture below see at show command for SW3).
  • For the remaining physical links, switches at both ends will negotiate who will leave the port in blocked state (switch with higher Bridge ID). On a link, only one end is leave blocked while the other end is always is passed in forwarding state. See proof on topology screen, here, none of physical links blocked at both ends at the same time. Let’s see for example what happens on the segment between SW3 and SW4, here, SW4 have a lower Bridge ID than SW3 therefore this one will pass his port ]n forwarding state (F0/4). Given that bridge priority of both switches are the same (default value of 32768) result that the factor that make difference when comparing Bridge Priority is MAC addresses – SW4 have a MAC address lower than that of SW3.

What can happen if unexpected switch is inserted to network-show spanning tree output

If now, we will re-draw the topology so that only active paths are shown then a nice tree (hence the term Spanning Tree) can be observed (picture below, left side). As can be seen all traffic flows are aggregated in one of core switch. 

What can happen if unexpected switch is inserted to network-spanning trees

If now, intentionally or by mistake, a new switch with a lower than existed bridge priority is inserted then a suboptimal STP topology can form. Let’s suppose that the new switch with pre-configured bridge priority of 20480 (lowest in topology) is connected directly to SW3. In that case, after STP re-calculation, a new root bridge will be elected (that new switch) and another active/blocked links topology will be established. If compare this topology (shown in picture below) to initial one then differences are obvious. As show in previous picture (right side) all the traffic are now aggregated in SW3 – a switch that is less powerful than the core switches, so a inevitable bottleneck point will occur in this network.

What can happen if unexpected switch is inserted to network-networkdiagram after new switch added

If to look at cost of path from SW3 to root bridge then, now, it become more expensive, which means that path is crossing along more ports. In show spanning-tree command, the value of 57 added by 3 time cost of FastEthernet port (19 as of IEEE standard).

Obviously such scenarios should be avoided. There are techniques like BPDU guard/filter that once configured can automatically block the ports or cancel any BPDU swapping toward such unexpected switches, but this is a subject for another post so enough for today.

Rețele Private VLAN (PVLAN) – part II

După o scurtă introducere în rețele PVLAN făcută în prima parte a articolului am să continui cu o prezentare pentru câteva exemple de utilizare PVLAN. În părțile ce vor urma planific să descriu tipuri de interfețe trunk specifice PVLAN pe switch-uri Cisco, condițiile impuse pentru un switch peste care sunt tranzitate VLAN-uri private precum și modul în care pot fi configurate PVLAN-urile pe un switch distribuit VMware.

Exemple de utilizare

Să analizăm câteva use case-uri tipice pentru rețele PVLAN:

  • rețea hosting provider
  • rețea demilitarizată DMZ
  • rețea de backup
  • rețea desktop-uri virtuale VDI.

Rețea hosting provider

O rețea a unui hosting provider adună la un loc (într-un singur network) nodurile/host-urile mai multor clienți – ultimii, funcție de dimensiunea provider-ului posibil să ajungă de ordinul sutelor, miilor, zecilor de mii s.a.m.d. Sigur, fiecare client își dorește un mediu de rețea securizat și izolat de restul clienților, dar, securizat și izolat însemnă VLAN-uri și subnet-uri IP dedicate per client or acest lucru e aproape imposibil pentru hoster-ii mari, pe de-o parte VLAN-urile tradiționale suferă de o scalabilitate proastă – un maxim de 4094 de VLAN ID-uri și pe de altă parte overhead în plus pe IP – adrese IP pierdute pe numărul/broadcast-ul rețelei, interfețe L3 pe router/firewall pentru fiecare subnet, overhead administrativ.

PVLAN-urile oferă o soluție simplă și totodată scalabilă pentru așa fel de scenarii. În loc de VLAN-uri/subnet-uri separate per client, va fi suficient ca în rețeaua hoster-ului să se configureze un PVLAN pe o singură rețea L3. Pentru segregare, fiecare client se va ancora în VLAN-ul secundar izolat din PVLAN. Serviciile partajate se vor conecta în port-urile promiscous pe VLAN-ul primar. Design-ul va consuma două VLAN-uri (primar și secundar izolat), două adrese IP și o singură interfață pentru router/firewall folosit ca și default gateway la subnet. Soluția e de-a dreptul fără limite de scalabilitate, imaginați-vă că aceasta e bună și pentru de un hoster cu 1M de clienți – indiferent de dimensiune se vor consuma aceleași două VLAN-uri și un singur subnet iar clienții în același timp vor rămâne izolați între ei. Vedeți mai jos o ilustrare pentru un astfel de scenariu:


Rețea demilitarizată DMZ

În rețeaua unei companii PVLAN-urile se pot dovedi extrem utile pe segmentul ei de DMZ. Într-o arhitectură de rețea securizată se obișnuiește ca serverele cu acces public ale companiei să fie organizate într-un segment de rețea izolat, separat de celelalte servere interne. Respectivul segment formează așa numita zona demilitarizată DMZ a rețelei. Într-un DMZ, este permis accesul din rețeaua publică (Internet) la serverele din DMZ și totodată blocat pe alte rețele interne. Pe de altă parte, serverelor din DMZ le este permis să comunice cu rețelele interne. Segmentul de DMZ este separat de rețelele interne și rețeaua publică prin dispozitive firewall. Altfel spus, DMZ-ul permite expunerea controlată a unui grup de servere într-o rețea publică fără să se compromită securitatea pentru celelalte servere din infrastructură.

Chiar dacă oferă un layer în plus de protecție, DMZ-ul nu ne poate apăra de situațiile în care sunt compromise însuși servere din DMZ. Odată rupte – de exemplu prin exploatarea unei găuri în chiar sistemul de operare, intrusul poate încerca să obțină acces neautorizat în rețelele interne sau pe alte servere din DMZ. Toate serverele din DMZ rămân deschise unul în față de celălalt iar securitatea întregului ansamblu se raportează la securitatea celui mai slab protejat server.

Pentru a reduce vulnerabilitatea serverelor din DMZ în fața unui vecin compromis se pot utiliza rețelele private PVLAN. Să luăm ca exemplu scenariul din schema prezentată mai jos (stânga), avem aici un segment DMZ cu două servere DNS, un server de poștă și un server WEB. Serverele din DMZ nu au nevoie să comunice între ele cu excepția DNS-urilor care lucrează în failover unul pentru altul și care au nevoie să schimbe periodic informații între ele.


Pentru un setup cu PVLAN-uri serverele SMTP și WEB se vor plasa în Secondary Isolated VLAN al VLAN-ului privat iar serverele DNS se vor conecta în porturile asociate cu un Secondary Community VLAN dedicat. În așa fel, serverele DNS vor putea să comunice liber intre ele dar nu și cu celelalte servere din DMZ la fel și restul serverelor vor fi restricționate să comunice unul cu altul. Acum suprafața de atac va fi blocată pe perimetrul serverul compromis asigurându-se protecție pentru celelalte servere din DMZ.

Vom face același lucru și pentru cazul cu mai multe servere conectate în spatele unui Load Balancer, de exemplu într-o fermă de servere HTTP pentru un site WEB (vezi in desenul de mai sus pe dreapta). În regim normal serverele nu au nevoie să comunice între ele așa că pentru o securitate mai bună va fi bine să le izolăm între ele, de exemplu prin conectarea într-un Secondary Isolated VLAN dintr-un PVLAN.

Ce este interesant, migrarea de pe o arhitectură cu un singur VLAN pe una cu PVLAN poate fi realizată transparent, fără reconfigurări și întreruperea serverelor. Tot de ce este nevoie e ca pe switch-uri să se adauge VLAN-urile secundare după care să se modifice corespunzător configurația pe porturi. Nu se schimbă configurația IP nici pe servere nici pe echipamentul de rețea.

Rețea de backup

Chiar dacă un pic arhaică – mai ales pentru un mediu cu servere virtuale, arhitectura cu backup-ul serverelor inițiate de agenți instalați direct pe OS și cu trafic de backup împins printr-o rețea dedicată are totuși drept la viață. Într-o astfel de arhitectură, fiecare server are câte o conexiune în plus la rețea – una dedicată traficului de backup prin care agentul de backup transmite traficul de backup spre aplicația de backup. Pe partea de backup, toate serverele figurează ca făcând  parte dintr-o singură rețea de date. Evident că o așa arhitectură nu e tocmai securizată, paradoxal pe de-o parte serverele sunt organizate în subnet-uri protejate de firewall-uri iar pe de altă parte legate transparent într-o rețea mare de backup. Rețeaua de backup poate să devină mediul pentru propagarea unui atac pe servere – de exemplu de pe un server compromis într-o rețea pe un alt server dintr-o altă rețea; sau răspândirea virușilor s.a.m.d.

O soluție pentru securizarea rețelei de backup poate fi implementarea de PVLAN. Într-un PVLAN, serverele se vor conecta în porturi configurate pentru Secondary Isolated VLAN astfel încât să nu se observe unul pe celălalt iar serverul cu aplicația de backup se va conecta într-un port promiscous în așa fel încât să poată fi accesat de celelalte servere. Mai jos o ilustrare pentru o astfel de arhitectură.


Rețea desktop-uri virtuale VDI

Pentru o securizare în plus se obișnuiește ca într-un VDI (mai ales pentru unul cu destinație publică ca de ex. desktop-urile virtuale dintr-o bibliotecă sau kiosk-urile din salile unui hotel) să se restricționeze comunicațiile între desktop-urile virtuale. Ca și în case-urile de mai sus, obiectivul se atinge simplu prin implementarea de PVLAN (btw supported pe switch-uri virtuale vSphere/Hyper-V) cu includerea desktop-urilor virtuale în VLAN-ul secundar izolat din PVLAN.