How to achieve hiding internal URLs and HTTP dynamic redirection with F5 XC HTTP Load Balancer
XC HTTP LB basic rewrite options By default, XC with or without a route rewrites the Host value of the client’s http request to the origin server’s FQDN name in the origin pool (only if the origin server is FQDN, not IP address). Under the XC origin pool, you can control the SNI selection for the origin pool. Sometimes having not the correct SNI could generate 400 errors for nginx origin web servers, for example. XC HTTP LB Host 3xx Redirection Under the XC HTTP LB route, you can configure host redirection even for non standard port. If you don't configure an explicit path option, then XC will auto-redirect and keep the original URL. I found this not something well-explained. For basic HTTP to HTTPS redirection you can easily enable it under and HTTPS LB and the only issue is it assumes that HTTP is on port 80, so for custom redirection from HTTP on port other than 80 you need to use the below methods. For any F5 experts out there this is similar to the default http to https redirection in F5 BIG-IP ADC or F5 NEXT ADC with system iRule _sys_https_redirect. You can even configure the HTTP LB to listen on ports other than the default ones (80 for HTTP or 443 for HTTPS) and to redirect to also not custom ports. In some cases you will need to add the FQDN domain with the non-custom port. Some web browsers send traffic to not custom ports with the port in the host name and this could cause XC not to match the traffic. To test this with "curl" that can even be directed with the "resolve" option to HTTP LB that the public DNS still does not direct to it. This is similar to F5 BIG-IP/NEXT iRule TCL scripting where " [HTTP::uri] " or " [HTTP::path] " are used depending if you want the redirect to keep the query parameters or not. XC HTTP LB internal URL Rewrite Under the XC HTTP Route advanced options, you can find the Request URL rewrite can match on prefix or even a regex to be used. This in some cases helps for apps that don't handle very well 3xx redirects (mobile apps are one such case) as for example "/test" URL is auto-changed to "/" otherwise 404 code would be seen if the page does not exist! The rewrite option seems particularly useful for Customer Edge (CE) deployments that are inside the customer networks RE > CE traffic where the HTTP LB is on the RE and the origin servers in the origin pool are on the CE and the SSL/IPSEC tunnel between RE and CE is used to stich things. Sometimes a rewrite of the response is needed, as for example to change the HTML response image urls to the new ones. In this case, Nginx containers can be used with XC Virtual Kubernetes (v8ks) that will offer this advanced function with the "filter" option that I have described in article F5 XC vk8s workload with Open Source Nginx | DevCentral In F5 BIG-IP or NEXT with iRules or even Local Traffic Policies this functions are implemented. XC Custom Route Under Multi-Cloud App Connect, you can create custom route objects that can also do redirects or rewrite request URLs. The main benefit is that many HTTP LB can use the custom routes and can attach custom Request/Response headers or Cookies, even on Redirect routes that the Simple Routes that are directly created under the HTTP LB can't. This can be useful for some logic in mobile apps or custom non browser Agents like API clients. Summary The XC Cloud provides many options. In the future, you might see things like TCL iRule scripts that will offer advanced changes and rewrites of even HTTP request and response bodies without adding Nginx containers. So, keep checking release notes at Release Changelogs | F5 Distributed Cloud Technical Knowledge to not miss anything new that is released! Useful Links: Layer 7 Content Routing in F5 XC | DevCentral How to setup path-based routing or application load-balancing – F5 Distributed Cloud Services How to do an URL redirection? – F5 Distributed Cloud Services How do I configure a redirection with a URL that contains path and query parameters? Article DetailF5 XC Session tracking with User Identification Policy
With F5 AWAF/ASM there is feature called session tracking that allows tracking and blocking users that do too many violations not only based on IP address but also things like the BIG-IP AWAF/ASM session cookie. What about F5 XC Distributed Cloud? Well now we will answer that question 😉 Why tracking on ip addresses some times is not enough? XC has a feature called malicious users that allows to block users if they generate too many service policy, waf , bot or other violations. By default users are tracked based on source IP addresses but what happens if there are proxies before the XC Cloud or NAT devices ? Well then all traffic for many users will come from a single ip address and when this IP address is blocked many users will get blocked, not just the one that did the violation. Now that we answered this question lets see what options we have. Reference: AI/ML detection of Malicious Users using F5 Distributed Cloud WAAP Trusted Client IP header This option is useful when the client real ip addresses are in something like a XFF header that the proxy before the F5 XC adds. By enabling this option automatically XC will use this header not the IP packet to get the client ip address and enforce Rate Limiting , Malicious Users blocking etc. Even in the XC logs now the ip address in the header will be shown as a source IP and if there is no such header the ip address in the packet will be used as backup. Reference: How to setup a Client IP as the Source IP on the HTTP Load Balancer headers? – F5 Distributed Cloud Services (zendesk.com) Overview of Trusted Client IP Headers in F5 Distributed Cloud Platform User Identification Policies The second more versatile feature is the XC user identification policies that by default is set to "Client IP" that will be the client ip from the IP packet or if "Trusted Client IP header" is configured the IP address from the configured header will be used. When customizing the feature allows the use of TLS fingerprints , HTTP headers like the "Authorization" header and more options to track the users and enforce rate limiters on them or if they make too many violations and Malicious users is enabled to block them based on the configured identifier if they make too many waf violations and so much more. The user identification will failover to the ip address in the packet if it can't identify the source user but multiple identification rules could be configured and evaluated one after another, as to only failover to the packet ip address if an identification rule can't be matched! If the backend upstream origin server application cookie is used for user identification and XC WAF App firewall is enabled and you can also use Cookie protection to protect the cookie from being send from another IP address! A nice option is that you can search the request and security logs using the "user id" as by default in XC for example you can't search the logs using the Authorization header that for example OAUTH and API traffic uses or a cookie like the session JSESSION or PHPSSEID but this way you can! The demo juice shop app at https://demo.owasp-juice.shop/ can be used for such testing! References Lab 3: Malicious Users (f5.com) Malicious Users | F5 Distributed Cloud Technical Knowledge Configuring user session tracking (f5.com) How to configure Cookie Protection – F5 Distributed Cloud Services (zendesk.com) Configure Rate Limiting per User | F5 Distributed Cloud Technical KnowledgeF5 XC CE Debug commands through GUI cloud console and API
Why this feature is important and helpful? With this capability if the IPSEC/SSL tunnels are up from the Customer Edge(CE) to the Regional Edge(RE), there is no need to log into the CE, when troubleshooting is needed. This is possible for Secure Mesh(SM) and Secure Mesh V2 (SMv2) CE deployments. As XC CE are actually SDN-based ADC/proxy devices the option to execute commands from the SDN controller that is the XC cloud seems a logical next step. Using the XC GUI to send SiteCLI debug commands. The first example is sending the "netstat" command to "master-3" of a 3-node CE cluster. This is done under Home > Multi-Cloud Network Connect > Overview > Infrastructure > Sites and finding the site, where you want to trigger the commands. In the VPM logs it is possible to see the command that was send in API format by searching for it or for logs starting with "debug", as to automate this task. If you capture and review the full log, you will even see not only the API URL endpoint but also the POST body data that needs to be added. The VPM logs that can also be seen from the web console and API, are the best place to start investigating issues. XC Commands reference: Node Serviceability Commands Reference | F5 Distributed Cloud Technical Knowledge Troubleshooting Guidelines for Customer Edge Site | F5 Distributed Cloud Technical Knowledge Troubleshooting Guide for Secure Mesh Site v2 Deployment | F5 Distributed Cloud Technical Knowledge Using the XC API to send SiteCLI debug commands. The same commands can be send using the XC API and first the commands can be tested and reviewed using the API doc and developer portals. API documentation even has examples of how to run these commands with vesctl that is the XC shell client that can be installed on any computer or curl. Postman can also be used instead of curl but the best option to test commands through the API is the developer portal. Postman can also be used by the "old school" people 😉 Link reference: F5 Distributed Cloud Services API for ves.io.schema.operate.debug | F5 Distributed Cloud Technical Knowledge F5 Distributed Cloud Dev Portal ves-io-schema-operate-debug-CustomPublicAPI-Exec | F5 Distributed Cloud Technical Knowledge Summary: The option to trigger commands though the XC GUI or even the API is really useful if for example there is a need to periodically monitor the cpu or memory jump with commands like "execcli check-mem" or "execcli top" or even automating the tcpdump with "execcli vifdump xxxx". The use cases for this functionality really are endless.
