Controlling Traffic to a Virtual Server on F5

There are multiple ways to control what traffic is allowed or not allowed through a BIG-IP F5 system or for specific Virtual Servers (VS). The following method uses F5’s AFM (Application Firewall Manager) module to create security policies which are then applied to a specific VS. For this method example, traffic from three specific hosts will be allowed to a specific VS, while all other traffic is blocked. The below diagram illustrates the environment used:

Take note that for this configuration all platforms involved are configured on VMWare’s ESXi virtualization platform, this include all servers, PCs, and F5 BIG-IP instances running.

In this example the VS ( is setup for TCP port 80 (HTTP) traffic only. This within itself controls some of the allowed traffic flow (assuming there are not other VS configured to accept all traffic) by only allowing port 80 traffic destined to the VS to be processed. An address list is created with the addresses that are allowed to the VS and then a Network Firewall Policy Rule is created and applied to the specified VS with an accept action. To finish this method, a block rule is added to the Network Firewall Rule Policy rule-set to drop all other traffic.

The first step is to create a Address List by going to Security > Network Firewall > Address Lists and either clicking the plus sign under Address Lists:

or selecting Create on the next screen:

Enter the following Information (Only Name and Addresses are required):
CreatingAddressList Click finish when completed. A side note, the first time I did this I spent a few moments figuring out you must push enter after typing the address in the address field.

The next step is to create the Rule Policies by going to Security > Network Firewall > Active Rules and clicking the plus sign under Active Rules:

or selecting Add on the next screen:

Enter the following information:

  • Context: Virtual Server – VS_Name
  • Policy: New – Policy_Name
  • Rule Properties:
    • Name: Rule_Name
    • Description: Rule_Description
    • Source:
      • Address/Region: Specify
      • Type: Address List
      • List: Address_List (From last step)
    • Action: Accept

NewRule Select Repeat to move onto the next rule.

For the next rule include the following information:

  • Rule Properties:
    • Name: Rule_Name
    • Description: Rule_Description
    • Source:
      • Address/Region: Any
    • Action: Drop

NewRule2 Click Finished when all set. When adding the block rule, or any other rule for that matter, make sure to add to the current policy. Otherwise, the current policy will be overwritten along with any rules in those policies. In this example creating the blocking rule improperly would overwrite the policy with the allow rule and block ALL traffic to the VS.

Once completed, it is now time to test. Attempting to browse to from an “allowed IP address” should allow access to the site while browsing from an IP address that isn’t on the list should be blocked.


As always, make sure to not make changes to production platforms without proper change management. It is also highly advisable that any planned changes (especially when introducing new technology) are tested in a lab environment.


Attacking HSRP and how to protect it

I covered HSRP (Hot Standby Router Protocol) in a previous post that went into great detail on how HSRP functioned and a few enhancements to it. This time around I figured it would be fun to see what we could do to a typical HSRP deployment, and then research ways to further protect it.

For this scenario the following topology will be used:


. The topology includes a basic HSRP configuration between two routers (R01 and R02), a basic layer 2 switch (sw1) and a webserver sitting on the “Internet”. For verification purposes, the active HSRP router is checked:  12

With the verification completed its now time to start the reconnaissance. For this Kali Linux was used along with a hand full of tools running on it. This post is not intended to explain how to use the tools and will not go over them, a simple Google search will give you all the information you need for that…

A quick wireshark trace shows there is in fact HSRP traffic flowing on the subnet:Screenshot from 2015-07-19 09_37_13

The attack is launched and a new HSRP takes over as active:

Screenshot from 2015-07-19 09_41_253

Executing the attack alone is enough to cause a DDoS event for that subnet. All traffic is routed to the rouge Active HSRP “router” and if it is not setup properly will cause all traffic destined for an outside subnet to be dropped:4

For some a DDoS is the end goal of the attack, but that’s not as fun as being able to be in the middle of the traffic without users even knowing. For the MITM to be successful a few things needed to be configured on the kali Linux device in order to get traffic flowing properly. Once setup traffic was able to leave the subnet:


Now that the attacker is in the middle of all traffic leaving the subnet, it is possible to sniff any traffic going through with wireshark. If anything is sent in clear text (unencrypted) the attacker is able to see it in wireshark including login information:Screenshot from 2015-07-19 10_05_10

The easiest way to add a layer of protection onto HSRP is to utilize MD5 authentication. This can be accomplished through key chains, key strings, or a mixture of the two. The configuration to use a key string is very straight forward. On all routers participating in HSRP for that group add the single command line: standby [HSRP group #] authentication text  [Authentication String]. Once configured, all devices will use the string to hash message data. If a router attempts to join the HSRP group with a incorrect key the following warning is seen:


SNMP traps can be setup so that an alert is sent immediately if the bad authentication is seen allowing for network staff to investigate the issue.

CCIE Homelab Tips, Tricks, & Thoughts CSR1000V memory optimization

With the completion of my Master’s degree I now have more free time to start preparing for my deep dive into my CCIE studies. Recently I’ve been working on getting my lab environment together. What I’ve decided was to do a mixture of both physical hardware and virtual instances which includes a few “pods” of routers and switches along with a ESXi Server running both Cisco VIRL and a large number of CSR100V instances. There are both pros and cons to using either hardware or virtual instances, something I will probably cover at a later time, including a rundown of my lab environment once its completed.

Today I want to go over something neat I discovered when researching how to deploy CSR1000Vs for my lab, disabling large pages in ESXi. Disabling Large Pages in ESXi is essentially deduplication for memory. This allows for a very large memory savings when running multiple instances of similar VMs (such as 20 CSR1000V instances!). For me on 10 CSR1000V instances I saw RAM use go from 33GB down to 12GB, which allows for even more instances to be installed on the same amount of hardware.

Enabling this feature takes a matter of minutes to implement, and gives a great memory use savings.

*Please note*: I have not done extensive research on the interworking of what enabling this feature does. I have not personally run into any performance issues running this on my CCIELab ESXi host which runs mostly CSR instances with a few other VMs. If you are going to deploy this on a host that is used for other things please take baselines and use caution when deploying. I would also recommend not deploying this feature in production without first consulting a VMware expert.

Now to the fun part!

First lets take a note of what memory usage is currently at:

To have the change take affect, the VMs have to be powered on after the change is made, so next is to power down all of your VMs.

After the VMs are powered down follow the following steps:

1. Navigate to Configuration
2. Under Software: Select Advanced Settings

3. Select “Mem”
4. Locate “Mem.AlocGuestLargePage” and set its value to 0

5. Select Ok
6. Power on VMs

It will take a few minutes (roughly 5 – 10) for the CSRs to fully boot up and for ESXi to deduplicate memory. I recommend turning up as many instances you can and coming back in 10 minutes to enjoy all of the additional memory you just acquired.

And of course, a screenshot of my 10 CSR100Vs running with less memory utilization 🙂


Sending commands to multiple Terminal Sessions at one time

A few weeks ago I had to hunt down PCs but had no idea where they physically were or what switchports they were connected to. To determine the location of a PC the following steps were taken:

  1. Ping the PC IP address – This refreshes the ARP and MAC-Address tables with the current MAC address and ports
  2. Determine the MAC address from the ARP table on a layer three device < show ip arp | include IP_ADDRESS >
  3. Trace the MAC address to it’s port < show mac address-table address MAC_ADDRESS >

While in a normal environment, the most switches that have to be touched is usually two (the default gateway, and the switch the device is connected to). However, for this instance 9 switches were daisy chained together in a ring like fashion… Throw in the fact roughly 35 devices needed to be traced I got tired of clicking through all of the terminal sessions and tracing the MAC address I got annoyed pretty quickly… Luckily I remembered something that stuck out to me from one of the wonderful CBT Nuggets of the VIRL series by Anthony Sequeira. He had mentioned the Command (Chat) Window in SecureCRT that could be used to send the same commands to multiple sessions at the same time. After poking around for a few minutes I figured out how to enable the chat window and have it send commands to every active session. Once setup tracking down those PCs was a lot less time consuming!

Setting up Command Chat is pretty straight forward.

First enable Command (Chat) Window under View:

After the Chat Window has been enabled SecureCRT will have a blank box at the bottom of the screen as seen below:

The chat window alone will not send commands to all of the active sessions, that feature must b enabled by right clicking in the chat window and selecting “Send Commands to All Sessions”:

After that anything typed into the chat window will be sent to all active sessions!

Here is the command window in action:



As with anything always be mindful of what you are doing! Having sessions open that you may forget about and then push commands to can be very very bad!!

A few examples of when this can come in handy are:

  • Tracing MAC addresses
  • Tracing routes across the network
  • Creating the same VLANS across multiple switches
  • Pushing standard configurations for initial configurations in VIRL
  • Many more!

Two months fly by quick!

Wow its been two months already!!

Lots of things have been going on that have kept me away from doing much of anything outside besides work and school work. Luckily I am officially done with my Master’s degree, which means I will have plenty of time to start creating more posts like I had originally intended. With the completion of my Master’s degree I will be able to start preparing for the CCIE written.

That’s it for today, just wanted to say that things aren’t dead!

To homelab or not to homelab….? That is a question.. (Part 2) – Diagrams

In my previous post in this series I went over the gradual growth of my lab from just being on my desk to having its very own 42u network rack. Since then, my lab has grown and changed. Previously I was using the virtual switch right on my esxi hosts (which were 5.1), along with having separate local storage and managing them individually.

Today my virtual environment is managed by vCenter, has centralized storage, runs ESXi 5.5, and utilizes Cisco Nexus 1000v for distributed switching. I plan to do another post eventually on my centralized storage setup running FreeNAS so I won’t be talking directly about it too much. Instead, through building out my virtualized environment I realized that I don’t actually have any diagrams for my home network / lab.

The first diagram I started to work on is for my “server” environment. This includes my storage servers as well as my ESXi hosts and the guests running on the guests. It took a bit of time to figure out a good way to represent how the VMS are connected to the network but I think I found a good way of doing it.


Going through the diagram:

  • ESXi-1 (C1100)
    • 72 GB ECCRAM
    • iSCSI LUN
    • Dual connected IP and iSCSI connectivity
    • 25 Configured VMs
      • 11 Active
  • ESXi-2 (C1100)
    • 72 GB ECC RAM
    • iSCSI LUN
    • Dual connected IP and iSCSI connectivity
    • 29 Configured VMs
      • 11 Active
  • unRAID (WhiteBox)
    • 8GB RAM
    • Single DataStore (1 Disk Parity) [ 22TB]
    • Dual connected IP connectivity
  • FreeNAS (C2100)
    • 24GB ECC RAM
    • Single DataStore (1 Disk Parity) [ 22TB]
    • Dual connected IP connectivity
    • Quad connected iSCSI connectivity
    • Dual PSU
  • Access Switch
    • WS-C2960S-48LPS-L
  • Other
    • APC BR1500G (1500VA/865W)
    • APC BR24BPG (additional four 9Ah batteries for UPS)


Next steps will be to add the rest of the equipment, and my CCIE Lab. Can’t forget about that 🙂

Upgrading ESXi 5.X, the easy way

I am currently in the process of collecting the several pieces I need for my next lab upgrade (shared storage for my ESXi hosts) and as part of my preparation I needed to upgrade my hosts to the latest version of ESXi. I spent about 45 minutes reading through all of the documentation on upgrading and then attempting to find the upgrade tool mentioned in VMware documentation. Through my search I discovered a very simple way to upgrade 5.x

  1. Download the update zip from VMware.
  2. Upload the update image to a Datastore on the host with the following steps:
    1. Browse to Configuration > Hardware > Storage
    2. Right click on the Datastore where you want to store the image and click on “Browse Datastore…”:ESUP1
    3. Upload the update file:ESUP2
  3. Once uploaded, turn down all VMs and put the host into maintenance mode.
  4. SSH to the ESXi host (may require SSH to be turned on) and enter the following command:
    esxcli software vib install -d /UPDATE_LOCATION/
  5. After the upgrade finishes you will see a similar screen:esxi upgrade
  6. Reboot
  7. Once your host finishes booting you are all set and ready to turn up your VMs (don’t forget to exit maintenance mode)!

I was able to use this method to upgrade my 5.1 host and my 5.5U1 host to 5.5U2 in a manner of minutes (the 5.1 host took a little longer to come back after the reboot, just give it time).

As always, test before implanting anything in production, make proper backups, verify upgrade paths, etc.

Happy upgrading!