iRule to Redirect to Another VS on the same LTM
Hi guys - I'm trying to get the following scenario working: My domain "; maps to a public IP "1.1.1.1" and I have a virtual server configured on my F5 with "1.1.1.1:443" I have two unrelated applications with competing requirements running on different URIs on the same domain , one is a HR application (/abc) and the other is a inventory application (/def) I need to create a design which accomodates both applications with a single domain name, and find a way to accomodate both their conflicting requirements under the same domain name To solve this problem, I thought that I should do something like this, on the main virtual server 1.1.1.1:443, I put in an iRule with the following code: when HTTP_REQUEST { if { [string tolower [HTTP::uri]] starts_with "/abc" } { virtual VS2 } else if { [string tolower [HTTP::uri]] starts_with "/def" } { virtual VS3 } else { HTTP::respond 200 content "Unrecognised URI, please recheck your address" } } This would redirect incoming requests with "/abc" in the URI string to VS2 and incoming requests with "/def" in the URI string to VS3. Then I could create customised solutions for both applications in their respective virtual servers. So drawing this flow out, I think this is how it would look: But what I don't understand is how the Return Traffic and the Persistence Profiles work in this scenario. How do I make sure that the traffic flows this way: User to Server: User > VS1 > VS2 > Pool 2 (Server) Server to User: Pool 2 (Server) > VS2 > VS1 > User Do I do SNAT Auto Map on both VS1 and VS2 or do I just do SNAT Auto Map on VS2 with Auto Last Hop enabled? And on the question of persistence, if I intend to use source_addr persistence - I would definitely not be able to do a SNAT Auto Map on VS1, how do I then ensure that when the server responds, VS2 sends the traffic back to the user via VS1?How to configure source NAT for health monitors?
I have following deployment scenario: dmz firewall --- F5-BIGIP --- internal firewall/router --- servers F5 acts as gateway and uses 192.168.0.0/24 subnet on VLAN facing internal firewall. Virtual servers don't use source NAT. Internal firewall filters out all packets with private source IP incoming to gateway interface so all health monitors requests are rejected by internal firewall (as they originate from 192.168.0.0/24). Is there any way to perform SNAT on health monitors to make them originate from our WAN IP? I wanted to use iptables prerouting srcnat but it doesn't seem to be available on F5. There doesn't seem to be arbitrary SNAT functionality either. Would AFM allow to achieve such behavior?
Cannot disable snat in iApps
Hi, I have recently stuck with an issue on LTM which seems odd. When I set Source Address Translation to None in normal VIPs, client addresses get to the servers just fine but when I do the same thing for VIPs which I have created using iApp templates with the same configuration, client addresses keep getting translated to the inside interface IP of the LTM. It seems really strange to me because the procedure I take to disable the snat for both of them is the same but I get different result. I will paste the configuration of both here and I will appreciate if someone can help me about this. ===Virtual Setup : without-iapp_vs=== ltm virtual without-iapp_vs { destination 192.168.10.60:http ip-protocol tcp mask 255.255.255.255 pool without-iapp_pool profiles { tcp { } } security-log-profiles { "Log all requests" } source 0.0.0.0/0 translate-address enabled translate-port enabled vs-index 17 } ===Pool Setup : without-iapp_pool=== ltm pool without-iapp_pool { members { 172.16.187.2:http { address 172.16.187.2 session monitor-enabled state up } } monitor http-80 ===Virtual Setup : with-iapp.app/with-iapp_redir_vs=== ltm virtual with-iapp.app/with-iapp_redir_vs { app-service /Common/with-iapp.app/with-iapp destination 192.168.10.42:http ip-protocol tcp mask 255.255.255.255 profiles { with-iapp.app/with-iapp_f5-tcp-lan { context serverside } with-iapp.app/with-iapp_f5-tcp-wan { context clientside } http { } } rules { _sys_https_redirect } source 0.0.0.0/0 translate-address enabled translate-port enabled vs-index 92 } ===Pool Setup : none=== ===Virtual Setup : with-iapp.app/with-iapp_vs=== ltm virtual with-iapp.app/with-iapp_vs { app-service /Common/with-iapp.app/with-iapp destination 192.168.10.42:https fallback-persistence with-iapp.app/with-iapp_source-addr-persistence fallback-persistence-type source-address ip-protocol tcp mask 255.255.255.255 persist { with-iapp.app/with-iapp_cookie-persistence { default yes } } policies { with-iapp.app/with-iapp_policy { } } pool with-iapp.app/with-iapp_pool profiles { with-iapp.app/ASM_with-iapp_policy { } with-iapp.app/with-iapp_client-ssl { context clientside } with-iapp.app/with-iapp_f5-tcp-lan { context serverside } with-iapp.app/with-iapp_f5-tcp-wan { context clientside } with-iapp.app/with-iapp_http { } with-iapp.app/with-iapp_oneconnect { } with-iapp.app/with-iapp_optimized-caching { } with-iapp.app/with-iapp_server-ssl { context serverside } with-iapp.app/with-iapp_wan-optimized-compression { } websecurity { } } security-log-profiles { "Log illegal requests" } source 0.0.0.0/0 translate-address enabled translate-port enabled vs-index 93 } ===Pool Setup : with-iapp.app/with-iapp_pool=== ltm pool with-iapp.app/with-iapp_pool { allow-snat no app-service /Common/with-iapp.app/with-iapp load-balancing-mode least-connections-member members { 172.16.37.27:https { address 172.16.37.27 app-service /Common/with-iapp.app/with-iapp session monitor-enabled state up } } monitor https_443 slow-ramp-time 300
