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.


Wireshark & F5 Plugins make for easier troubleshooting

I recently was directed towards a wonderful plugin for Wireshark that helps with troubleshooting F5 TCPDUMPS. With my first F5 exam coming up very shortly, I figured I’d take a break from studying and do a write-up on this helpful addition. I will not be covering installation of this plugin, that can be find on the DevCentral page for the plugin (requires login).

 How the plugin works:

The plugin itself utilizes “noise” information that can be included by the F5 TMM system during a TCPDUMP.  This extra noise information is primarily used by F5 support in troubleshooting, it provides great value when attempting to trouble shoot problems on your own. The plugin within Wireshark is able to automatically dissect the noise included and provide it as an additional section within Wireshark allowing for easy use of the new information.
Figure-1: Frame Detail Pane

As can bee seen, there are three new panes provided specifically for F5; Low Details, Medium Details, and High Details.

Below is the explanation of the three levels, this information was pulled directly from an F5 Support Document and I have included screenshots to show each level.

The noise levels include the following details:
Low Details

  • Ingress: A flag indicating whether TMM is sending or receiving the packet. A zero (0) indicates that TMM is sending the packet, while a non-zero number indicates that TMM is receiving the packet.
  • Slot: The chassis slot number of the TMM that is handling the packet.
  • TMM: The number of the TMM that is handling the packet.
  • VIP: The name of the virtual server that is handling the connection. Prior to BIG-IP 11.2.0, the name was limited to 16 characters. In BIG-IP 11.2.0 and later, the name is limited to 96 characters.

Figure-2: Low Noise

Medium Details

  • Flow ID: A number identifying a flow within TMM. The same flow ID can be used for different flows in different TMMs. Also, the same flow ID can be re-used for a different flow within the same TMM at a different time.
  • Peer ID: A number identifying the peer flow within TMM. Note that the same peer ID can be used for different flows in different TMMs. Also, the same peer ID can be re-used for a different flow within the same TMM at a different time.
  • Reset Cause: In BIG-IP 11.2.0 and later, the reset cause (if available) is included for TCP reset packets. For more information, refer to SOL13223: Configuring the BIG-IP system to log TCP RST packets. 
  • Connflow Flags: Diagnostic information used by F5 Technical Support. 
  • Flow Type: Diagnostic information used by F5 Technical Support.
  • High Availability Unit: Diagnostic information used by F5 Technical Support.
  • Ingress Slot: Diagnostic information used by F5 Technical Support.
  • Ingress Port: Diagnostic information used by F5 Technical Support.

Figure-3: Medium Noise

High Details

  • Peer IP Protocol: The IP protocol of the peer flow. This field is not populated prior to BIG-IP 11.0.0.
  • Peer VLAN: The VLAN ID number that is associated with the peer flow.
  • Peer Remote Address: The IP address of the host on the far end of the peer flow.
  • Peer Local Address: The IP address used by TMM for the peer flow.
  • Peer Remote Port: The protocol port of the host on the far end of the peer flow.
  • Peer Local Port: The protocol port used by TMM for the peer flow.

Figure-4: High Noise

While not all of the information is useful, there are a few major parts I’d like to point out that I feel would be a great help when troubleshooting.

Low Details:

  • Ingress: This allows for a quick way to determine if the packet you are seeing is inbound to the BIG-IP system or outbound
  • Slot: In larger deployments, utilizing chassis based Viprons, it is sometimes helpful to know which blade is handling the traffic
  • VIP: This allows you to easily determine if the VIP handling the traffic, is the one you’d except

Medium Details:

  • Reset Cause:  While the only portion of Medium Details I’ve used so far, being able to quickly determine why the RST occurred can help take time off of how long services are down during a troubleshooting exercise

High Details:

  • Peer IP Protocol: While not always necessary, this can be helpful for troubleshooting non TCP/UDP traffic (such as VPN)
  • Peer VLAN: This is the destination VLAN (VLAN where servers usually sit)
  • Peer Remote Address: This is the destination address
  • Peer Local Address: This is the source address
  • Peer Remote Port: This is the destination port
  • Peer Local Port: This is the source port

 Creating TCPDUMPS for the plugin:

Disclaimer: These steps are merely to demonstrate how to include the required “noise” in your TCPDUMP, as always please exercise caution when using new commands / features for the first time. I recommend testing in a lab/non-production environment first, even though it seems nothing bad should happen surprises happen (and sometimes they aren’t good surprises).

To use the plugin, you simply must state the amplitude of noise you desire within your TCPDUMP command on your interface argument

tcpdump -i <interface>:<noise amplitude>

The following noise arguments are possible:

  • n:  Low details
  • nn:  Low and medium details
  • nnn:  Low, medium, and high details

An example of a TCPDUMP with Low, Medium, and High Details:

tcpdump -s0 -ni ExternalDMZ:nnn -w /var/tmp/ExtendedF5.pcap

For the extra information to be included, you cannot pull the trace from a physical interface, it must be from a VLAN.

Using the Plugin:

After the plugin is installed, and you have captured your TCPDUMP its time to open up Wireshark!

Figure-5: Wireshark with plugin installed

Immediately you can see that the additional information is being included in the capture without even having to do anything.

Picking a frame allows you to drill down into more information including the three new levels for F5.

In addition, its now possible to trace flows for F5 IP, TCP, and UDP

Figure-6: Additional Analyze options

That’s the basic overview of the plugin provided by the wonderful F5 DevCentral community. There is other functionality in the plugin but I have not had a chance to look into, I may do another post with the additional functionality at a later time…

F5 Wireshark Plugin (Requires login) [Download plugin, Instructions, additional information]
SOL13637: Capturing Internal TMM Information with TCPDUMP [Additional Information]

F5 AAA (local roles) with Cisco ACS 5.x

I’ve spent the last few days putting together a how-to on setting up F5 BIG-IP to utilize Cisco ACS TACACS+ for user authentication. While there are guides online I couldn’t find one that shows the configuration of both systems so I figured it could be helpful to others.

The guide covers how to setup both Cisco ACS and F5 BIG-IP to utilize users locally configured on the BIG-IP system to use ACS for authentication & accounting. Authorization will not be covered in this guide as it will be handled locally by the BIG-IP system.

I spent a few hours trying to get formatting right for wordpress but I couldn’t get it to where I wanted so sadly it has to be hosted elsewhere.

Click here for the PDF form of how to guide hosted on Google Drive!