F5 NGINX Plus R34 Release Now Available
We’re excited to announce the availability of F5 NGINX Plus Release 34 (R34). Based on NGINX Open Source, NGINX Plus is the only all-in-one software web server, load balancer, reverse proxy, content cache, and API gateway. New and enhanced features in NGINX Plus R34 include: Forward proxy support for NGINX usage reporting: With R34, NGINX Plus allows NGINX customers to send their license usage telemetry to F5 via an existing enterprise forward proxy in their environment. Native support for OpenID Connect configuration: With this release, we would like to announce the availability of native OpenID Connect (OIDC) module in NGINX Plus. The native module brings simplified configuration and better performance while addressing many of the complexities with the existing njs-based solution. SSL Dynamic Certificate Caching: NGINX Plus R34 builds upon the certificate caching improvements in R32 and introduces support for caching of dynamic certificates and preserving this cache across configuration reloads. Important Changes In Behavior Removal of OpenTracing Module: In NGINX Plus R32, we announced deprecation of the OpenTracing module in favor of OpenTelemetry module introduced in NGINX Plus R29. , and was marked to be removed with NGINX Plus R34. The OpenTracing is now being removed from NGINX Plus effective this release. Changes to Platform Support Added Platforms: Alpine Linux 3.21 Removed Platforms: Alpine Linux 3.17 SLES12 Deprecated Platforms: Alpine Linux 3.18 Ubuntu 20.04 New Features in Detail Forward proxy support for NGINX usage reporting In the previous NGINX Plus release (NGINX Plus R33), we introduced major changes to NGINX Plus licensing requiring all NGINX customers to report their commercial NGINX usage to F5. One of the prime feedback we received for this feature was the need to enable NGINX instances to send telemetry via existing outbound proxies, primarily for environments where NGINX instances cannot connect to the F5 licensing endpoint directly. We are pleased to note that NGINX Plus R34 introduces support for using existing forward proxy solutions in customers environment for sending licensing telemetry to F5. With this update, NGINX Plus can now be configured to use the HTTP CONNECT proxy to establish a tunnel to the F5 licensing endpoint to send the usage telemetry. Configuration The following snippet shows the basic NGINX configuration needed in the ngx_mgmt_module module for sending NGINX usage telemetry via a forward proxy solution. mgmt { proxy HOST:PORT; proxy_username USER; #optional proxy_password PASS; #optional } For complete details, refer the docs here. Native support for OpenID Connect configuration Currently, NGINX Plus relies on a njs-based solution for OpenID Connect (OIDC) implementation that involves intricate JavaScript files and advanced setup steps, which are error-prone. With NGINX Plus R34, we're thrilled to introduce native OIDC support in NGINX Plus. This native implementation eliminates many of the complexities of the njs-based approach, making it faster, highly efficient, and incredibly easy to configure, with no burdensome overheads of maintaining and upgrading the njs module. To this effect, a new module ngx_http_oidc_module is introduced in NGINX Plus R34 that implements authentication as a relying party in OIDC using the Authorization Code Flow. The native implementation allows the flexibility to enable OIDC authentication globally, or at a more granular, per-server or a per-location level. It also allows effortless auto-discovery and retrieval of the OpenID providers' configuration metadata without needing complex external scripts for each Identity Provider (IdP), greatly simplifying the configuration process. For a complete overview and examples of the features in the native implementation of OIDC in NGINX Plus and how it improves upon the njs based implementation, refer the blog. Configuration The configuration to setup OIDC natively in NGINX Plus is relatively straightforward requiring minimal directives when compared to the njs based implementation. http { resolver 10.0.0.1; oidc_provider my_idp { issuer "https://provider.domain"; client_id "unique_id"; client_secret "unique_secret"; } server { location / { auth_oidc my_idp; proxy_set_header username $oidc_claim_sub; proxy_pass http://backend; } } } The example assumes that the “https://<nginx-host>/oidc_callback” redirection URI is configured on the OpenID Provider's side. For instructions on how to configure the native OIDC module for various identity providers, refer the NGINX deployment guide. SSL Certificate Caching improvements In NGINX Plus R32, we introduced changes to cache various SSL objects and reuse the cached objects elsewhere in the configuration. This provided noticeable improvements in the initial configuration load time primarily where a small number of unique objects were being referenced multiple times. With R34, we are adding further enhancements to this functionality where cached SSL objects are reused across configuration reloads, making the reloads even faster. Also, SSL certificates with variables are now cached as well. Refer the blog for a detailed overview of this feature implementation. Other Enhancements and Bug Fixes Keepalive timeout improvements Prior to this release, idle keepalive connections could be closed any time the connection needed to be reused for another client or when the worker was gracefully shutting down. With NGINX Plus R34, a new directive keepalive_min_timeout is being introduced. This directive sets a timeout during which a keepalive connection will not be closed by NGINX for connection reuse or graceful worker shutdown. The change allows clients that send multiple requests over the same connection without delay or with a small delay between them, to avoid receiving a TCP RST in response to one of them, if not for network reasons or non-graceful worker shutdown. As a side-effect, it also addresses the TCP reset problem described in RFC 9112, Section 9.6, when the last sent HTTP response could be damaged by a followup TCP RST. It is important for non-idempotent requests, which cannot be retried by client. It is however recommended to not set keepalive_min_timeout to large values as this can introduce an additional delay during worker process shutdown and may restrict NGINX from effective connection reuse. Improved health check logging NGINX Plus R34 adds logging enhancements in the error log for better visibility while troubleshooting upstream health check failures. The server status code is now logged on health check failures. Increased session key size Prior to R34, NGINX accepted an SSL session with maximum 4k(4096) bytes. With NGINX Plus R34, the maximum session size has been increased to 8k(8192) bytes to accommodate use cases where the sessions could be larger than 4k bytes. For ex. in cases where a client certificate is saved in the session, with tickets (in TLS v1.2 or older versions), or with stateless tickets (in TLS v1.3) the sessions maybe of noticeably large size. Certain stateless session resumption implementations may store additional data as well. One such case is with JDK, which is known to include server certificates in the session ticket data which roughly doubles the decoded session size. The changes also include improved logging to capture cases when sessions are not saved in shared memory due to size. Changes in the Open Telemetry Module TLS support in OTEL traces: NGINX now allows enabling TLS for sending OTEL traces. It can be enabled by specifying "https" scheme in the endpoint as shown. otel_exporter { endpoint "https://otel.labt.fp.f5net.com:4433"; trusted_certificate “path/to/custom/ca/bundle“; # optional } By default, system CA bundle is used to verify endpoint's certificate which can be overridden with "trusted_certificate" directive if required. For a complete list of changes to the OTEL module, refer the NGINX OTEL change log. Changes Inherited from NGINX Open Source NGINX Plus R34 is based on NGINX mainline release and inherits all functional changes, features, and bug fixes made since NGINX Plus R33 was released (in NGINX Open source 1.27.3 and 1.27.4 mainline versions) Features: SSL Certificate Caching "keepalive_min_timeout" directive The "server" directive in the "upstream" block supports the "resolve" parameter. The "resolver" and "resolver_timeout" directives in the "upstream" block. SmarterMail specific mode support for IMAP LOGIN with untagged CAPABILITY response in the mail proxy module. Changes: Now TLSv1 and TLSv1.1 protocols are disabled by default. An IPv6 address in square brackets and no port can be specified in the "proxy_bind", "fastcgi_bind", "grpc_bind", "memcached_bind", "scgi_bind", and "uwsgi_bind" directives, and as client address in ngx_http_realip_module. Bug Fixes: gzip filter failed to use preallocated memory" alerts appeared in logs when using zlib-ng. nginx could not build libatomic library using the library sources if the --with-libatomic=DIR option was used. QUIC connection might not be established when using 0-RTT; the bug had appeared in 1.27.1. NGINX now ignores QUIC version negotiation packets from clients. NGINX could not be built on Solaris 10 and earlier with the ngx_http_v3_module. Bugfixes in HTTP/3. Bugfixes in the ngx_http_mp4_module. The "so_keepalive" parameter of the "listen" directive might be handled incorrectly on DragonFly BSD. Bugfix in the proxy_store directive. Security: Insufficient check in virtual servers handling with TLSv1.3 SNI allowed to reuse SSL sessions in a different virtual server, to bypass client SSL certificates verification (CVE-2025-23419). For the full list of new changes, features, bug fixes, and workarounds inherited from recent releases, see the NGINX changes . Changes to the NGINX Javascript Module NGINX Plus R34 incorporates changes from the NGINX JavaScript (njs) module version 0.8.9. The following is a list of notable changes in njs since 0.8.7 (which was the version shipped with NGINX Plus R33). Features: Added fs module for QuickJS engine. Implemented process object for the QuickJS engine. Implemented the process.kill() method. Bug Fixes: Removed extra VM creation per server. Previously, when js_import was declared in http or stream blocks, an extra copy of the VM instance was created for each server block. This was not needed and consumed a lot of memory for configurations with many server blocks. This issue was introduced in 9b674412 (0.8.6) and was partially fixed for location blocks only in 685b64f0 (0.8.7). Fixed XML tests with libxml2 2.13 and later. Fixed promise resolving when Promise is inherited. Fixed absolute scope in cloned VMs. Fixed limit rated output. Optimized use of SSL contexts for the js_fetch_trusted_certificate directive. For a comprehensive list of all the features, changes, and bug fixes, see the njs Changelog.
Forward proxy with SSL passthrough - SWG license required?
Hi, At one site with a single v15 VE I need to proxy outbound traffic, but without SSL inspection. Most docs relating to SSL passthrough assume that targets are internal and pooled but this is not my scenario: internal clients must connect to numerous (but specified) external URLs outside my control, and whose IPs are constantly changing. This similar query states solved via iApp but does not specify which one, or much detail on the final config. Regarding the license aspect, other proxy-related posts refer to the need for SWG license (which I don't have) - would I need this? The documentation for this use-case is unclear; any comments/tips gratefully received! Cheers, auto
HTTP Explicit Proxy - V11.5+
Problem this snippet solves: This iApp configures an Explicit Proxy using the new "Explicit" Proxy Mode that was introduced into the HTTP Profile in BIG-IP 11.5. You only need LTM or APM provisioned. It creates all configuration components required including: DNS Resolvers TCP Tunnel HTTP Profile (Explicit) Default Connect Handling set to Allow SNAT Pools (Optional) SNAT Default is Automap If you require the Explicit Proxy to listen on more than 1 port e.g 3128 and 8080, simply just create another Application Service. Contributed by: Brett Smith How to use this snippet:
Squid forward caching proxy server conflicting with Load Balancer; images, JS, CSS not rendering in application
Have an interesting one here that I hope others can help unravel. A user tells me that the website application, which sits behind an F5 LB, is not rendering properly: E.g.: is missing images, stylesheets, javascript files, and the like. And it's not just this user but a colleague at his workplace has the same issue and seemingly others in the company also can reproduce this issue. I will say that this client (as in the company) is the only one who has reported such an issue. No other companies who use the application are reporting pages not rendering content properly. He had tried testing with a work laptop, work phone, personal phone, over the company network, cellular network, and home network and using multiple browsers. It was consistent across multiple browsers. I asked him to clear cache and cookies and that did not help. Here are the results of his testing: Work laptop on home network: Pass. Work laptop on company network : Fail. Work laptop at their customer's location (possibly connected to customer's network): Fail Work phone on company network: Fail. Work phone on cellular network (Verizon)*: Fail. Personal phone on cellular network (AT&T)*: Pass. Work colleague of user laptop connected to said colleague's phone configured as hotspot (Sprint) (not sure if devices are work or personal)**: **This was conducted while on company premises. It didn't seem to matter what browser was employed. I didn't get a report that it worked in one browser but not another, for instance. To make a long story short, I asked him to send me a fiddler log and the logs showed something that I cannot reproduce on my end. The Fiddler log shows the page loaded with HTTP 200 but the content on the page (i.e. JavaScript files, stylesheets, images) show HTTP 304. In the response headers, under Transport, for all requests, I see Connection: close and Via: 1.1 {unique ID} (squid/3.5.23) (The unique ID is some kind of specific value. It might be sensitive information so I decided to not include it in this post). For , the response header Cache shows: X-Cache: MISS from {unique ID} X-Cache-Lookup: HIT from {unique ID}:{Port number} For , the response header Cache shows: X-Cache: HIT from {unique ID} X-Cache-Lookup: HIT from {unique ID}:{Port number} I don't recall seeing anything like this before. It looks to be Squid, a caching and forward proxy server, that is sitting in front of the client and making requests to the LB. Since this company is the only one who has reported this issue and I cannot reproduce it on my end, it's probably safe to say that either this company is running Squid, their ISP is running Squid, or even both. I pressed the user to inquire with the company's IT if they are running any proxies and the answer was no. It's certainly possible the company's IT could be mistaken. Today, the user says that he came into his office and everything is working now. He tried Firefox, IE, wireless network, cellular network and does not understand why it's working. The likely possibilities I can think of as to what and why is: Squid cache was flushed, which means this problem may return in the future. Squid was not configured properly by company's IT/ISP and now it is, thus resolving the issue. Squid was taken offline and the client is connecting directly to the LB now. What I am very concerned about is what happens if the company reports the same issue or maybe another company who is running Squid or some other forward caching/proxy server reports the same issue? I really don't know if this is something where I have to tell the user that this is not our problem, this is your IT infrastructure and/or your local ISP's problem. In other words, whether the Squid server is configured properly or not, is this something where the LB needs to be configured such that it works around the problem? Does that make sense? If there is a configuration change that I need to enact on the LB, what are these changes and what are step-by-step instructions? I'm sorry for the long-winded explanation but I'm trying to be detailed and thorough with this. Thank you very much.
Forward SSL proxy or Proxy SSL ?
Hi We want to create new Virtual server wildcard Outbound with standard type and port 443. The thing is we want to decrypt to inspect and modify some http header of some host too. example. If we access ";, F5 should perform irule and send it to pool A but if other user access ";, F5 should do nothing and send traffic normally. What need to do between Forward SSL proxy and Proxy SSL? Is both an additional license? Thank you
SSL forward proxy integration with FireEye to inspect HTTPS
We are trying to integrate F5 with FireEye to be able to inspect HTTPS traffic with the FireEye NX solution. We started off by creating a simple SSL forward proxy setup to verify the SSL proxy functionality as follows. We used the IAPP f5.airgap_egress.v1.0.0rc4 and modified some details, like we created a separate virtual server for 443 for testing purposes. Considerations Some applications do not work when SSL interception is enabled like Skype. It is needed to have a full list of host names, IP destination of traffic that cannot be decrypted and has to be excluded. SSL forward proxy only works if clients default gateway is self IP of F5. If external gateway is used all traffic is not being intercepted or matched by the virtual servers. SNAT has to be enabled otherwise connections are not being established. Downside is that FireEye is unable to see the original source IP address. Perhaps HTTP header X-forwarded-for will solve this. SSL forward proxy with route domains Lab setup After setting up the basic SSL forward proxy we continued creating to route domains. Created to routes one from route domain 0 to route domain 1 and one from route domain 1 to the external router. For your information we used only 1 Big IP device. Considerations All traffic works fine UDP, HTTP, but HTTPS always results in an SSL error message, because there are two SSL client sessions. To be able to decrypt the traffic and forwarding it unencrypted from route domain 0 to route domain 1 we have to disable SSL on the server side on virtual server wildcard 443 in route domain 0 and we have to disable client side ssl on the SSL wildcard virtual server located in route domain 1 so it will accept connections unencrypted. The following Irule is being used to simply disable SSL traffic on the server side communicating towards route domain 1. On the SSL wildcard virtual server in route domain 1 we disable Client ssl profile and enable server SSL to re-encrypt the connection. Now when we try to open a SSL website like gmail.com we receive the following error. It happens with every SSL website w In Wireshark we observer that the handshake is failing to the Gmail website, but the client proxy SSL connection is successfully setup with TLS 1.2. The TLS session towards google is TLSv1, so perhaps that’s the problem here. Does anyone has some recomendations why this is happening?Add banner to HTML Pages with no control over HTTP code
I'm quite new to iRules, but I have a requirement to have the F5 add a banner message at the top of certain webpages. We aren't able to modify the source HTML of the pages though. Is this possible with either iRules or content profiles? A bit more background: The F5 is acting as a forward proxy for Internet access. Our management have requested that we add a warning message to certain websites, but not block them entirely. Thanks in advanceHTTP FORWARD PROXY IAPP IRULE NOT WORKING
How can i get the HTTP FORWARD PROXY IAPP to work effectively. In my environment,i have a requirement to use LTM as a forward Proxy to .i have used the HTTP PROXY IAPP and edited the DNS to reflect the dns server in my environment, and i can confirm DNS is working. However,users can't browse with their proxy ip and port configured on their browsers, even though chat messages are landing Is there any tweak that needs to be done on Irule or the likes to make it work?. I will post the irule generated by the iapp in the comments
IP forwarding to a pool
How do you configure an F5 to just pass off traffic to the back-end pool of servers without modifying the packets nor load balancing the traffic after it has made the initial connection to the back-end server. I am just looking for the F5 to listen for traffic on the VIP, pick the next available server in the pool, and then forward all of the traffic from that session to the one pool member. Almost a simple reverse proxy.F5 LTM AS A FORWARD PROXY/TMG REPLACEMENT FOR HTTP/HTTPS FOR MOBILE USERS
How can the F5 be used as a Forward Proxy for mobile users to the internet. My initial setup included the mobile users sending requests to F5,which sends requests to Traffic Servers,and Traffic servers have another leg which sends requests to the internet. The traffic servers however are capping (capacity),and so,there is a requirement for the F5 to be used as a FORWARD PROXY for mobile users. Kindly list the steps to follow, e.g, 1,create standard virtual server, 2, use the irule HTTP Forward Proxy - v3.2 e.t.c Thanks
