Using an iRule to specify multiple allowed ports for a virtual server

I apologize; I'm not sure I follow your concern.

In general, the best approach to this is to create two separate Virtual Servers: one listening on 443 (with POOL1 assigned) and the other listening on 5443 (with POOL2 assigned). A BIG-IP takes a default deny posture (unless you are using AFM and override this), so your default condition above (

discard

Dear Vernon, Thanks for your answer, you answered my question by offering a better solution, I applied it and it worked! But I had issue with how f5 put check-mark and omit that check-mark in virtual server properties, as I mentioned above, I mean when we choose "all ports", it omits the "port translation" check-mark which was there at first place, and I think it is not suitable, because in many cases we need that "port translation"

Hi,

Port translation is to change virtual server destination port with pool member port.

When you use "all ports" option, the destination port will be the same client side and server side.

A BIG-IP generally has two "sides" for a traffic flow: the "client-side" (traffic flowing between client and the Virtual Server) and the "server-side" (traffic flowing between the BIG-IP and the next hop, often a pool member, but may be a routed next hop). When you select "port translation", the destination port on the server-side -- as it egresses the BIG-IP -- is set to match the pool member. Normally, if a Virtual Server is associated with a pool, it is providing a specific service. As such, a VS with a pool normally has a single port associated with it. Occasionally, the pool is actually next hop gateways. This is the ordinary use-case for a port-wildcard (i.e., the "all ports" option) Virtual Server that has an associated pool. In this configuration, it is not desirable to translate the port (and indeed, no port translation can occur because the pool member has its port set to 0). So, the default action when one sets "all ports" on the VS is to disable port translation, because this is the most common use-case for that option.

A BIG-IP generally has two "sides" for a traffic flow: the "client-side" (traffic flowing between client and the Virtual Server) and the "server-side" (traffic flowing between the BIG-IP and the next hop, often a pool member, but may be a routed next hop). When you select "port translation", the destination port on the server-side -- as it egresses the BIG-IP -- is set to match the pool member. Normally, if a Virtual Server is associated with a pool, it is providing a specific service. As such, a VS with a pool normally has a single port associated with it. Occasionally, the pool is actually next hop gateways. This is the ordinary use-case for a port-wildcard (i.e., the "all ports" option) Virtual Server that has an associated pool. In this configuration, it is not desirable to translate the port (and indeed, no port translation can occur because the pool member has its port set to 0). So, the default action when one sets "all ports" on the VS is to disable port translation, because this is the most common use-case for that option.

Good point. "Gateway" is a bit ambiguous :). Typical next hops would be firewall appliances or IP routers. If it's routers, it allows static next hop redundancy but with health detection. So consider if you have two routers and you want to round-robin traffic between then. You could create a wildcard VS with two pool members; namely, the two router next hop addresses. Naturally, you would also apply a health monitor, so if a router goes down, the LTM would stop forwarding traffic. This can be done with OSPF equal cost, for example, but that is substantially more complex to setup and manage.

Alternatively, with the firewall case, the next hop is a firewall. Since BIG-IP sends all traffic in a flow to the same selected destination, this works well for even firewall clusters. Again, a health monitor would ensure LTM would stop forwarding traffic to a firewall that becomes unavailable.

Good point. "Gateway" is a bit ambiguous :). Typical next hops would be firewall appliances or IP routers. If it's routers, it allows static next hop redundancy but with health detection. So consider if you have two routers and you want to round-robin traffic between then. You could create a wildcard VS with two pool members; namely, the two router next hop addresses. Naturally, you would also apply a health monitor, so if a router goes down, the LTM would stop forwarding traffic. This can be done with OSPF equal cost, for example, but that is substantially more complex to setup and manage.

Alternatively, with the firewall case, the next hop is a firewall. Since BIG-IP sends all traffic in a flow to the same selected destination, this works well for even firewall clusters. Again, a health monitor would ensure LTM would stop forwarding traffic to a firewall that becomes unavailable.