How to config PBR

In case you want to use the proxy to forward the client requests to the public internet, it will be necessary to allow traffic from the proxy IP address on the firewall ACL. In case you use SNAT on your forwarding virtual servers, the SNAT address used by the load balancer needs to be permitted on the firewall ACL (as it is replacing the original client IP address or the IP address of the proxy - both are the source IPs).

In case no SNAT is used on the virtual servers, it is necessary to create routes on the ISP router to make sure responses from the internet will be routed back properly to the proxy or to the client by using the floating self IP on northern interface of your BIG-IP as next hop.

Is the tcpdump showing something, if you try to get traffic on port 80 through the BIG-IP?

Would you provide us the output of the following, please:

tmsh list net vlan
tmsh list net self  
tmsh list net route  
tmsh list ltm pool  
tmsh list ltm virtual  

Hi Stephan How will I add another L3 forwarding virtual server to use multiple source subnets? I already have the below to direct to default gateway.

          ltm virtual /Common/forward-to-Internet_vs {
description "Outbound traffic to Internet"
destination /Common/0.0.0.0:0
ip-forward
mask any
profiles {
    /Common/IP-Gateway { }
}
source 0.0.0.0/0    <<<<>>>>>
translate-address disabled
translate-port disabled
vlans {
    /Common/vlan-external
    /Common/vlan-internal
}
vlans-enabled

}

How will I add another L3 forwarding virtual server to use multiple source subnets?

 

you have to duplicate virtual server and configure one source subnet per virtual server.

 

anyway, you know 0.0.0.0/0 means all subnets, don't you?

 

How will I add another L3 forwarding virtual server to use multiple source subnets?

 

you have to duplicate virtual server and configure one source subnet per virtual server.

 

anyway, you know 0.0.0.0/0 means all subnets, don't you?

 

I was expecting to include multiple subnets in the source section, i have around 50. Not sure if I can use i-Rule here. Would that impact e-PVA forwarding?

why don't use one virtual server with source 0.0.0.0/0? if you want to forward traffic from some source only, you can drop/reject traffic from other source by irule.

e.g.

when CLIENT_ACCEPTED  {
   if { ![class match -- [IP::client_addr] equals trusted_source] } {
      reject
   }
}

I was expecting to include multiple subnets in the source section, i have around 50. Not sure if I can use i-Rule here. Would that impact e-PVA forwarding?

why don't use one virtual server with source 0.0.0.0/0? if you want to forward traffic from some source only, you can drop/reject traffic from other source by irule.

e.g.

when CLIENT_ACCEPTED  {
   if { ![class match -- [IP::client_addr] equals trusted_source] } {
      reject
   }
}

How about specifying 2 different wildcard virtual servers:

 

1. wildcard network virtual on address 0.0.0.0/0 with tcp/80 and source of 0.0.0.0/0 to capture the http traffic to be forwarded to the proxy server

 

2. wildcard network virtual on address 0.0.0.0/0 with all_protocols/0 and source of 0.0.0.0/0 to capture everything which is not matching tcp/80 and to forward according to the routing table

 

If multiple servers are configured, the "longest match" by following a precedence described in AskF5 SOL14800.

 

As I understood from a previous message, your ISP router handles the ACLs, right? But you can still apply plain packet filters or an iRule based ACL or AFM directly on your BIG-IP device.

 

Btw, a virtual server needs to be enabled only on the VLAN where the traffic is initiated on. I.e. client comes from VLAN "internal" and it´s request should be processed to whereever. So the associated virtual server only needs to be enabled on VLAN "internal" (it tracks the connection internally [including egress VLAN] and established a listener to forward the expected responses back to the client).

 

The iRule above will do the job in combination with your virtual server listening on the clientside VLAN. In case of a match, you simply use "forward" instead of assigning a pool. Everything else will go to the default pool of your virtual server (the web proxy, I guess).

To make it more visible in the iRule inside the else condition the web proxy pool is assigned:

rule myrule {  
    when CLIENT_ACCEPTED {  
        if {[class match -- [IP::client_addr] equals subnet_list]} {  
            forward  
        } else {  
            pool http_proxy_pool  
        }
    }
}

The proposed iRule is working on L3 only and perhaps on L4 in case you add a condition based on the protocol port.

That´s why the ePVA processing should not be affected.

Please use the following command to verify the acceleration level of your specific virtual servers:

tmsh show ltm virtual virtual_server_name

Before doing anything else please turn on the port lockdown (allow none) on the self IPs (as well for floating self IPs) associated with your production networks. Otherwise you have a good chance to be hacked ... Btw, port lockdown only affects the managability on a network interface and how it can be used as a listener for other services (including dynamic routing).

 

Why do you want to pass dynamic routing information through the BIG-IP to another L3 network? As the F5 is used as a L3 component in your environment, the floating self IPs on the different interfaces will be used as next hop (in static routes) on the locally attached devices.

 

The HSRP address of your ISP router´s southern interface will be configured as next hop for the default route on your BIG-IPs. That´s it in a typical deployment.

 

Running tcpdump with parameter "-ei 0.0" shows traffic on all visible interfaces including L2 data (MAC address and VLAN information). So you know, on which interface a packet can be seen.

 

But again, I´m not aware of a reason to route HSRP packets.

 

Generally if routing is required, a host or network virtual server with address translation disabled (destination NAT) in ForwardingIP mode will typically do the job. It requires static routes on the BIG-IP to forward traffic via a next hop to non-locally-attached networks.

 

Alternatively you can configure next hop pools (members are locally attached HSRP addresses of your peripheral firewall or router) as next hop information in a route or use it as a resource for a virtual server in PerformanceL4 mode (destination NAT disabled as well).