Exam Topics
- F5CAB2
- F5CAB2.03
- Consider the packet and/or virtual server processing order (wildcard vips)
- F5CAB2.03
Introduction
As your F5 BIG-IP deployment grows, it can become increasingly challenging to determine which listener a client will actually connect to.
When multiple objects share the same network or host address, it is critical to understand which Virtual Server, NAT, or SNAT object will match the traffic. Conflicts can arise not only between listener types but also among multiple Virtual Servers themselves.
This course will explain how the F5 BIG-IP selects the appropriate listener type and how it resolves matches when multiple Virtual Servers could apply.
F5 Listeners, Accepting Client Traffic
As explained in the ADC Concepts article, the F5 BIG-IP operates with a deny-by-default posture. This means no client traffic is accepted unless an administrator explicitly configures a listener to handle it.
There are three types of listener objects that can accept client traffic:
-
Virtual Server: A traffic management object defined by a virtual IP address and service (for example,
192.168.1.1:80). -
NAT: A Network Address Translation object that maps a IP to another IP.
-
SNAT: A Source Network Address Translation object that translates the client’s source IP address.

Before analyzing traffic flow behavior, the first step is to determine which type of listener will process the incoming connection.
Order of Precedence of Listeners (Virtual Server, NAT and SNAT)
Since a user connection can match multiple listener, the F5 Big IP need a rule to match the correct listener.
First and foremost, a client connection will always match the most specific object. By “most specific,” we mean the address with the highest precision. For example, a host address (10.10.10.10/32) is more specific than an entire network (10.10.10.0/24), and a network is always more specific than a wildcard (*) that matches any address.
It is important to note that the following order of precedence only applies when the address specificity is equal between listeners (for example, multiple listeners sharing the same host or network).
For example, a NAT configured with a host destination 10.10.10.10 will take precedence over a Virtual Server configured with a network destination 10.10.10.0/24, because a host address is more specific than a network address, regardless of the object type.
When addresses are equally specific, the simple rule of thumb for listener precedence is:
Virtual Server → NAT → SNAT
A Virtual Server always takes precedence over a NAT listener, and a NAT listener takes precedence over a standard SNAT listener.

This precedence logic applies to both destination IP and source IP matching.
For the destination address, a Virtual Server and a NAT listener can share the same IP address, for example 10.10.10.10. In that situation, the Virtual Server takes precedence.
For the source address, the principle is identical. If a Virtual Server and a NAT listener, using the origin address field, share the same source address, for example 192.168.10.10, the Virtual Server takes precedence.
When comparing a NAT and a SNAT that both reference the same source address, for example 192.168.10.10, the NAT takes precedence over the SNAT.
Virtual Server processing order
We have seen how the F5 BIG-IP selects the appropriate listener type when a collision occurs at the source or destination level. However, even after the Virtual Server listener type has been selected, multiple Virtual Servers may still overlap and compete for the same traffic.
The fundamental rule is simple: the connection always matches the most specific Virtual Server.
The order of evaluation is as follows:
-
Most specific destination address
A host Virtual Server is more specific than a network Virtual Server, which is more specific than a wildcard destination (0.0.0.0). -
Most specific source address
The same logic applies to the source: a host source is more specific than a network source, which is more specific than a wildcard source. -
Most specific destination port
A specific destination port (for example 80) is more specific than a wildcard port (*).
Destination address example
If you configure two Virtual Servers:
-
Virtual Server 1 with destination
10.10.10.10 -
Vortual Server 2 with destination
10.10.10.0/24

A client connecting to 10.10.10.10 will match VS1, because a host destination is more specific than a network destination.
Source address example
If two Virtual Servers share the same destination but differ on source:
-
Virtual Server 1: Source
192.168.10.0/24, Destination10.10.10.0/24 -
Virtual Server 2: Source
192.168.10.10, Destination10.10.10.0/24

A client with source 192.168.10.10 connecting to 10.10.10.10 will match Virtual Server 2, because a host source is more specific than a network source.
Port example
If both destination and source specificity are identical, the destination port determines the match:
-
Virtual Server 1:
10.10.10.10:80 -
Virtual Server 2:
10.10.10.10:*

A client connecting to 10.10.10.10:80 will match Virtual Server A, because a specific port takes precedence over a wildcard port.
Understanding this evaluation order is essential when designing overlapping Virtual Servers, as it ensures predictable and controlled traffic behavior.
Virtual Server processing order table
This leads to the following table, which summarizes the Virtual Server processing order when using host addresses, network addresses, and wildcard definitions.
🟡 Network (typically a network, like 10.10.10.0/24)
🔴 Wildcard match anything
🔵 Specific Port
| Order | Destination | Source | Service Port |
|---|---|---|---|
| 1 | Host | Host | Port |
| 2 | Host | Host | * |
| 3 | Host | Network | Port |
| 4 | Host | Network | * |
| 5 | Host | * | Port |
| 6 | Host | * | * |
| 7 | Network | Host | Port |
| 8 | Network | Host | * |
| 9 | Network | Network | Port |
| 10 | Network | Network | * |
| 11 | Network | * | Port |
| 12 | Network | * | * |
| 13 | * | Host | Port |
| 14 | * | Host | * |
| 15 | * | Network | Port |
| 16 | * | Network | * |
| 17 | * | * | Port |
| 18 | * | * | * |
In this table, the evaluation order becomes very clear: destination address first, then source address, and only finally the service port.
This logic can sometimes produce results that feel counterintuitive. For example, a Virtual Server configured with a host destination, a host source, and a wildcard service port (destination: 10.10.10.10:*, source : 192.168.10.10) will take precedence over another Virtual Server configured with a network destination, a host source, and a specific service port (destination: 10.10.10.10/24:80, source : 192.168.10.10).
Even though the first Virtual Server uses a wildcard port, it is still considered more specific overall because destination specificity is evaluated before the service port. Since a host destination is more specific than a network destination, it wins the match, regardless of the port definition.
Conclusion
Understanding listener precedence is essential as your F5 BIG-IP deployment grows. In general: Virtual Servers take precedence over NAT, which in turn takes precedence over SNAT.
It is important to note that this order of precedence applies only when there is a “culprit”, meaning multiple listeners match at the same level of address specificity (for example, the same host or network). In all cases, any listener with a more specific address always takes precedence.
When multiple Virtual Servers match at the same specificity, F5 evaluates them in the following order: destination address first, then source address, and finally the service port. Keeping these rules in mind ensures predictable traffic flow and proper listener selection.