F5 AFM Summary

The F5 AFM Firewall module is very different from your typical network firewall. It gives the end user much flexibility on how they can configure firewall features but it can also be confusing.

Understanding the filtering order is the first step to understanding how AFM works as a network firewall. I also highly recommend you review the AFM Operations Guide.

This article will provide you the basics but the operations guide is much more in-depth.

Filtering Order

The firewall rule lookup order is as follows.

  1. Global AFM Rules
  2. Route Domain AFM Rules
  3. Listener AFM Rules

Global Context

The global context sees all traffic that traverses the F5 regardless of the type of traffic or what route-domain the traffic is apart of. You can configure rules directly on the global context or configure rules within a policy and then apply that policy to the global context. I prefer the policy option since it gives you more flexibility.

Since the global context sees all traffic routed through the F5 BigIP, you can simply place all of your firewalls directly in the global context policy. If you don’t chose to put all of your rules in the global context, you will still need to use it to allow traffic to nat addresses. LTM nats are like virtual servers in a way but do not allow you to apply firewall rules to them so the global context must be used.

When to use the Global Context

1). Filtering all traffic

As I mentioned previously, you can use the global context to filter all traffic. This is ok if your BigIP isn’t going to have a large number of firewall rules. It is not the most efficient way to firewall traffic.

2). LTM Nats

As I mentioned previously, LTM nats do not allow you to apply a firewall policy. The global context is the only way to allow permit access to your LTM nats.

3). Special Cases

There are some instances were you may want to overwrite specific denies used on other firewall contexts. For example, I was working on a customer that had a large amount of AFM rules configured on their virtual forwarders.

Additionally, all of their vips also had policies with specific denies configured on each of these mentioned policies. The customer had a Cisco ASA with Anyconnect and the filtering for Anyconnect users was done on the ASA. I used the global context to add a permit statement for the subnet vpn users would source from which permitted traffic overwriting all of the denies configured in the other policies.


Using the Global Context for all firewall rules can be inefficient especially on a BigIP with a large number of rules. This is because every rule on the global context has to be evaluated until the permit or deny is matched. This is even worse if your using the implicit deny to drop traffic.

Using the Global Context along side of policies are your virtual servers can become very confusing. You can easily have conflicting rules. There is a show command that shows you if flows are permitted or denied so that can help. Many times users are unaware of this command.

Route Domain Context

AFM allows you to apply a firewall policy or configure rules on a specific route-domain. For reference, a route-domain is similar to a VRF on a Cisco device. It allows you to have separate routing tables for specific configurations.

Applying an AFM firewall policy to a route-domain is very similar to applying a policy to the global context. I don’t believe there are any differences except that traffic is only filtered within the route-domain the rules are applied. I would only recommend applying your rules on the route domain context if your using multiple route domains on your F5 BigIP.

The caveats I mentioned with the global context also apply to using rules applied directly to a route-domain.

Listener Context

You can apply a firewall policy on your virtual servers. This allows you to have very granular control over what source addresses can access your virtual servers. If you only use the listener context for firewalling, it can be much more efficient than using the global context. This is because only the rules on the listener are processed. If you put all of your firewall rules on the global context, all the rules for every virtual server on the AFM are evaluated until a match is found.

I proved this when I was working on an AFM client that had over 3000 firewall rules. We noticed throughput was not what the client expected. We had all of the firewall rules configured in a policy on their virtual forwarder that forwarded all traffic. I created a new forwarder for the specific vlan traffic was sourcing from and applied a policy that had under 20 rules specific to that vlan.

The throughput did increase by about 20-25% after the change. I was not seeing high cpu utilization or memory utilization on the BigIP before. The rules for the vlan were at the very bottom of the global policy meaning almost all of the existing 3k rules had to be evaluated before the rules for that vlan were evaluated.


Applying firewall policies directly onto virtual servers is very unpopular where I currently work even though it can be more efficient. This is because many of the BigIPs we manage have a large number of vips. Many times you can apply the same policy to these virtual servers but if you want different access for different virtual servers your going to have ton of firewall policies. Sometimes using the global context is worth the inefficients when it is easier to manage.


The F5 AFM Firewall module can be much easier to troubleshoot if you understand the firewall order. If your interested in more F5 articles click here!