How to achieve hiding internal URLs and HTTP dynamic redirection with F5 XC HTTP Load Balancer
This is a comprehensive list of the XC options to change the Host or URL values in the requests and to trigger dynamic redirections. 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 Distributed Cloud DNS GSLB implementing Split-DNS
Have you ever wondered how to achieve Bind-like 'VIEW' behavior with F5 XC Load Balancer where depending on the customer’s IP, different DNS responses are returned? Well wonder no more! F5 XC DNS Load Balancers have the topology load balancing feature from the start, but now you can use source IP prefix lists or BGP ASN numbers that opens the door to Split-DNS similar to the BIND "View" feature! The XC DNS Load Balancers rules nowadays have new options that can support EDNS Client Subnet (ECS) feature load balancing or BGP ASN load balancing. EDNS is like X-Forwarded-For Header as it sees the real client subnet and not the DNS local resolver server IP Address. For more information, I suggest checking out the link below: EDNS0 Implementation and Troubleshooting recommendations For anyone that has worked with F5 DNS/GTM BIG-IP, this is similar to creating custom topology records. For more information, I suggest checking out the link below: Achieving split DNS behavior through BIG-IP DNS wide IPs Configuring a DNS zone First, you need to configure a primary DNS zone as shown in the picture below or use the option "Allow Application Load Balancer Managed Records" that is described in the links below that allows a created F5 XC TCP or HTTP LB to be auto-added to the DNS primary zone in XC. For more information, I suggest checking out the links below: Manage DNS Zone | F5 Distributed Cloud Technical Knowledge Use F5 Distributed Cloud to control Primary and Secondary DNS The 2 DNS Load Balancer rules match either 46.233.56.0/24 or 0.0.0.0/0 that is any IP address, and this is why the Score is set to 110 for the first rule to have higher priority. For testing, the Linux "dig" command supports +subnet option to change the EDNS subnet for example "dig test.niki.com @ns1.f5clouddns.com +subnet=46.233.56.0". If you don’t choose any subnet, the EDNS will be your IP address. But remember that the system could add a default mask like /24 if you don’t specify +subnet command with a mask. When you specify with @ to send the traffic directly to ns1.f5clouddns.com or ns2.f5clouddns.com you don't have to change your public DNS records and you can first test the XC DNS setup and then configure DNS delegation on your primary DNS servers. If you are behind NAT or VPN, use What Is My IP Address - See Your Public Address - IPv4 & IPv6 to see your public IP address. Example DNS request that will be sent to the specific pool: dig test.niki.com @ns1.f5clouddns.com +subnet=46.233.56.1 Example DNS request that will be sent to the default pool: dig test.niki.com @ns1.f5clouddns.com +subnet=5.5.5.5 Example DNS request with no "+subnet": That will be sent to the specific pool as my IP matches 46.233.56.0 subnet, and it is auto-added to the EDNS in DNS request. dig test.niki.com @ns1.f5clouddns.com You can also use the ASN for this task, and the ASN is being compared to your EDNS subnet. There are a lot of tools to see your ASN number based on your IP address 😉 Summary: XC has new and new features every day, and the DNS Load Balancer service is a clear example of this. We will see what comes next!F5 XC Distributed Cloud HTTP Header manipulations and matching of the client ip/user HTTP headers
1 . F5 XC distributed cloud HTTP Header manipulations In the F5 XC Distributed Cloud some client information is saved to variables that can be inserted in HTTP headers similar to how F5 Big-IP saves some data that can after that be used in a iRule or Local Traffic Policy. By default XC will insert XFF header with the client IP address but what if the end servers want an HTTP header with another name to contain the real client IP. Under the HTTP load balancer under "Other Options" under "More Options" the "Header Options" can be found. Then the the predefined variables can be used for this job like in the example below the $[client_address] is used. A list of the predefined variables for F5 XC: https://docs.cloud.f5.com/docs/how-to/advanced-security/configure-http-header-processing There is $[user] variable and maybe in the future if F5 XC does the authentication of the users this option will be insert the user in a proxy chaining scenario but for now I think that this just manipulates data in the XAU (X-Authenticated-User) HTTP header. 2. Matching of the real client ip HTTP headers You can also match a XFF header if it is inserted by a proxy device before the F5 XC nodes for security bypass/blocking or for logging in the F5 XC. For User logging from the XFF Under "Common Security Controls" create a "User Identification Policy". You can also match a regex that matches the ip address and this is in case there are multiple IP addresses in the XFF header as there could have been many Proxy devices in the data path and we want see if just one is present. For Security bypass or blocking based based on XFF Under "Common Security Controls" create a "Trusted Client Rules" or "Client Blocking Rules". Also if you have "User Identification Policy" then you can just use the "User Identifier" but it can't use regex in this case. To match a regex value in the header that is just a single IP address, even when the header has many ip addresses, use the regex (1\.1\.1\.1) as an example to mach address 1.1.1.1. To use the client IP address as a source Ip address to the backend Origin Servers in the TCP packet after going through the F5 XC (similar to removing the SNAT pool or Automap in F5 Big-IP) use the option below: The same way the XAU (X-Authenticated-User) HTTP header can be used in a proxy chaining topology, when there is a proxy before the F5 XC that has added this header. Edit: Keep in mind that in some cases in the XC Regex for example (1\.1\.1\.1) should be written without () as 1\.1\.1\.1 , so test it as this could be something new and I have seen it in service policy regex matches, when making a new custom signature that was not in WAAP WAF XC policy. I could make a seperate article for this 🙂 XC can even send the client certificate attributes to the backend server if Client Side mTLS is enabled but it is configured at the cert tab.F5 XC vk8s workload with Open Source Nginx
I have shared the code in the link below under Devcentral code share: F5 XC vk8s open source nginx deployment on RE | DevCentral Here I will desribe the basic steps for creating a workload object that is F5 XC custom kubernetes object that creates in the background kubernetes deployments, pods and Cluster-IP type services. The free unprivileged nginx image nginxinc/docker-nginx-unprivileged: Unprivileged NGINX Dockerfiles (github.com) Create a virtual site that groups your Regional Edges and Customer Edges. After that create the vk8s virtual kubernetes and relate it to the virtual site."Note": Keep in mind for the limitations of kubernetes deployments on Regional Edges mentioned in Create Virtual K8s (vK8s) Object | F5 Distributed Cloud Tech Docs. First create the workload object and select type service that can be related to Regional Edge virtual site or Customer Edge virtual site. After select the container image that will be loaded from a public repository like github or private repo. You will need to configure advertise policy that will expose the pod/container with a kubernetes cluster-ip service. If you are deploying test containers, you will not need to advertise the container . To trigger commands at a container start, you may need to use /bin/bash -c -- and a argument."Note": This is not related for this workload deployment and it is just an example. Select to overwrite the default config file for the opensource nginx unprivileged with a file mount. "Note": the volume name shouldn't have a dot as it will cause issues. For the image options select a repository with no rate limit as otherwise you will see the error under the the events for the pod. You can also configure command and parameters to push to the container that will run on boot up. You can use empty dir on the virtual kubernetes on the Regional Edges for volume mounts like the log directory or the Nginx Cache zone but the unprivileged Nginx by default exports the logs to the XC GUI, so there is no need. "Note": This is not related for this workload deployment and it is just an example. The Logs and events can be seen under the pod dashboard and even the container/pod can accessed. "Note": For some workloads to see the logs from the XC GUI you will need to direct the output to stderr but not for nginx. After that you can reference the auto created kubernetes Cluster-IP service in a origin pool, using the workload name and the XC namespace (for example niki-nginx.default). "Note": Use the same virtual-site where the workload was attached and the same port as in the advertise cluster config. Deployments and Cluster-IP services can be created directly without a workload but better use the workload option. When you modify the config of the nginx actually you are modifying a configmap that the XC workload has created in the background and mounted as volume in the deployment but you will need to trigger deployment recreation as of now not supported by the XC GUI. From the GUI you can scale the workload to 0 pod instances and then back to 1 but a better solution is to use kubectl. You can log into the virtual kubernetes like any other k8s environment using a cert and then you can run the command "kubectl rollout restart deployment/niki-nginx". Just download the SSL/TLS cert. You can automate the entire process using XC API and then you can use normal kubernetes automation to run the restart command F5 Distributed Cloud Services API for ves.io.schema.views.workload | F5 Distributed Cloud API Docs! F5 XC has added proxy_protocol support and now the nginx container can work directly with the real client ip addresses without XFF HTTP headers or non-http services like SMTP that nginx supports and this way XC now can act as layer 7 proxy for email/smpt traffic 😉. You just need to add "proxy_protocol" directive and to log the variable "$proxy_protocol_addr". Related resources: For nginx Plus deployments for advanced functions like SAML or OpenID Connect (OIDC) or the advanced functions of the Nginx Plus dynamic modules like njs that is allowing java scripting (similar to F5 BIG-IP or BIG-IP Next TCL based iRules), see: Enable SAML SP on F5 XC Application Bolt-on Auth with NGINX Plus and F5 Distributed Cloud Dynamic Modules | NGINX Documentation njs scripting language (nginx.org) Accepting the PROXY Protocol | NGINX Documentation
