How to config PBR

But for rest traffic, say port 22 traffic coming from 10.99.0.0/24, they have to be directly routed to the Internet. F5 is acting as L3 hop between LAN and Internet and directing specific traffic to App servers.

 

what is 10.99.0.0/24? was it typo? if you mean 10.1.0.0/24 and 10.2.0.0/24, other traffic such as port 22 will match forwardToInternet_vs virtual server and be sent to internet gateway. it won't match WHTTP_vs virtual server because destination is not 10.206.0.4:8080.

 

So you say no i_Rule needed at all?

 

yes

 

What I mean is traffic from a sample internal subnet 10.99.0.0/24 will go directly to Internet gateway, without being forwarded to VS 10.206.0.4:8080 at all. That traffic might be FTP, SSH, etc. Only port 80/443/8080 traffic from 10.1.0.0/24 and 10.2.0.0/24 has to go to the VS 10.206.0.4:8080 for further treatment by my App servers.

 

i am a bit confused. virtual server is destination listener object. it (virtual server) will be triggered only when traffic matches address and port configured in destination setting.

 

for example, only traffic destined to 10.206.0.4 and port 8080 will trigger 10.206.0.4:8080. other traffic won't match the virtual server.

 

sol14800: Order of precedence for virtual server matching (11.3.0 and later)

 

http://support.f5.com/kb/en-us/solutions/public/14000/800/sol14800.html

 

What I mean is traffic from a sample internal subnet 10.99.0.0/24 will go directly to Internet gateway, without being forwarded to VS 10.206.0.4:8080 at all. That traffic might be FTP, SSH, etc. Only port 80/443/8080 traffic from 10.1.0.0/24 and 10.2.0.0/24 has to go to the VS 10.206.0.4:8080 for further treatment by my App servers.

 

i am a bit confused. virtual server is destination listener object. it (virtual server) will be triggered only when traffic matches address and port configured in destination setting.

 

for example, only traffic destined to 10.206.0.4 and port 8080 will trigger 10.206.0.4:8080. other traffic won't match the virtual server.

 

sol14800: Order of precedence for virtual server matching (11.3.0 and later)

 

http://support.f5.com/kb/en-us/solutions/public/14000/800/sol14800.html

 

the end client is not hitting the virtual address directly.

 

the virtual server address is not self ip, is it?

 

the end client is not hitting the virtual address directly.

 

the virtual server address is not self ip, is it?

 

Hi Sumanta,

 

I'm starting to think that you might not need a PBR iRule after all after reading the above conversation between yourself and Nitass. What you may be looking to achieve is adding a few routes to your configuration. However you need to provide more information. Please provide the details regarding your vlans, selfips and routes using the following tmsh commands below. A very basic high level diagram will also help if you have one showing where the subnets reside, where you have placed the virtual servers and where is the ISP router.

 

tmsh list net self tmsh list net vlan tmsh list net route

 

Also your iRule above looks to have an unnecessary if { if { condition. Also you are missing a closing bracket. Anyway we can park that for now. Lets see if adding simple routes might be able to solve your problem.

 

Thanks

 

Hi Sumanta,

given the drawing, I guess to try to accomplish the following:

1. HTTP requests from internal LAN users for servers in the public internet should be routed / balanced to the proxy server

1. Non-HTTP requests from internal LAN users and requests from the proxy server should simply be routed to the public internet through the ISP router

Did I get it right?

What is required?

a) internal router has a default route pointing to the floating self IP (the one mapped to traffic-group-1) on southern VLAN interface of your F5

b) the proxy server has a default route pointing to the floating self IP (the one mapped to traffic-group-1) on eastern VLAN interface of your F5

c) the F5 has a default route pointing to the HSRP address on southern VLAN of your ISP router

d) the ISP router needs to apply source NAT for all outgoing traffic OR the F5 applies source NAT (SNAT) for all outgoing traffic (1st choice requires multiple routes to reache the internal networks and proxy server network via next hop floating self IP and the F5´s northern VLAN; 2nd choice requires a route on your ISP router to use the floating self IP (mapped to traffic-group-1) on the northern VLAN of your F5 load balancer

To get things done step-by-step I would start with configuration of ALL outbound traffic straight forward through the ISP router.

Just use a network virtual server 0.0.0.0/0:any (all protocols) enabled on VLAN south and east in ForwardingIP mode and with SNAT automap enabled.

Will it pass through outgoing traffic?

Hint: if you want to SNAT outgoing ICMP traffic (actually all non-TCP/UDP traffic) it is necessary to run the following command:

tmsh modify ltm global-settings general snat-packet-forward enabled

tmsh save sys config

It should also be possible now to browse the internet from your proxy.

Continue, if the public internet can be reached both by clients and by your proxy.

Ready for the next step:

If the pool (containing the proxy server) is "green", it can be associated with a new virtual server.

This new virtual server is another network wildcard virtual server 0.0.0.0/0:80 (tcp) in PerformanceL4 mode with SNAT automap enabled and using the proxyserver pool. Make sure it is enabled on the southern VLAN (where the client´s requests are coming from) only! Otherwise it would catch the outbound requests of your proxy as well - a nice loop ...

Also click on address translation enabled, please.

The new virtual server will catch all client initiated http traffic and direct it to the proxy server(s).

The proxy will hopefully forward the clients request to the public internet.

Does it work?

Another virtual server with more or less the same configuration but listening on port 443 will catch outgoing https traffic if required.

But to get this working, the proxy needs to be able to intercept the SSL handshake. This is relatively easy in case the client is using the http CONNECT method.

I assume this will not be the case in your setup, as it would require the clients to be configured to use a proxy for internet access?

Perhaps some vendors are able now to craft a self-signed server certificate based on the SNI TLS attributes in real-time.

If your clients are indeed configured to use a proxy server, the setup above changes a bit.

In this case the virtual server to catch the clients requests will be of type host (/32 address) in combination with the proxy service port, PerformanceL4 mode, SNAT automap and the proxyserver pool assigned. Done.

I hope this helps a bit.

Thanks, Stephan

PS: Will go offline for today (0:45 a.m.)

Hi Sumanta,

according to your routing table you try to configure a network address as a next hop:

10.206.0.8 0.0.0.0 255.255.255.248 U 0 0 0 www-external

Please check your self IP addresses and existing routes for inconsitency.

tmsh list net route

tmsh list net self

Thanks, Stephan

Hi Stephan I have the below query. What is the difference between "source-address-translation" & "translate-address/port disabled"? Why do we need both?

 

ltm virtual /Common/Transparent-Proxy_vs { description "Transparent-Proxy virtual server" destination /Common/0.0.0.0:80 ip-protocol tcp mask any persist { /Common/Persistence-1 { default yes } } pool /Common/WHTTP_Transparent profiles { /Common/fastL4 { } } source 0.0.0.0/0 source-address-translation { type automap } translate-address disabled translate-port disabled vlans { /Common/vlan-ingress } vlans-enabled }

 

Hi Sumanta,

 

the "source-address-translation" is replacing the client´s IP address in the datagram when processing the packet. Leaving it set to enabled for this particular virtual server helps, if the web proxy does not have a route back to the client (responses always needs to be passed back through the BIG-IP - otherwise connections will be broken from the client´s perspective).

 

The "translate-address" parameter allows destination address translation. This is disabled by default for a network virtual server, as it is typically used to forward packets to the destination server.

 

For our specific purpose the "translate-address" needs to be set to enabled, as we want to modify the destination IP address to match the web proxy IP. Otherwise the web proxy will probably discard the packet.

 

Thanks, Stephan