can't access on prem dns when using F5LTM as a gateway
The title is the tl/dr. I have a server on an internal network that is set up to use our F5 as a gateway. I have all of the forwarding vip's set up and routed through snat pools. and if i set the server to use an external dns like google or opendns everything seems to work perfectly. however the server is being set up as an smtp server and needs to rely on our on prem dns for some mail destinations. side note, if forwarding vip's are set for snat automap, on prem dns works fine. i did watch traffic with tcpdump from the F5, on the internal network when using nslookup with both on prem and off prem dns servers, i could see traffic hit the outbound forwarding vip. however watching traffic on the external network, traffic appeared on the outbound forwarding vip's when using external dns servers. on prem seem to have died somewhere in the F5. can i fix this by just adding another outbound vip set to snat outmap to manage dns traffic? is that an appropriate fix?
Unable to ping from some self ip on Velos
Hello team, I have configured a tenant on my Velos, everything works fine but, recently I have verified that when I try to ping to my default gw with the interface asociate to a self ip yellow-fe ping is ok but, wher i try to do it by using another interface associate to a different self ip such as Mam_Fe ping does not works as expected. I have attached the evidence. I have reconfigured the vlan on my blade with no success; i've veified everything on my F5 but it seems that the configuration is ok. Somebody could help me for fixing this problem ? Many thanks in advance for your time . Awaiting your news.
Round-robin method not load balanced
I have configured BIG-IP 1600 to distribute the load to two servers in a round-robin fashion, but only one of them is communicating and the load is not distributed. We have confirmed that all Pool Nodes for load balancing are green, but we would like to know the cause of the problem. Persistence does not seem to be set.
Upgrade Path for BIG-IP 2000 – Out of Warranty and EoRMA Status
Hi Team, We are currently running BIG-IP LTM and AFM version 14.1.4.6 on a BIG-IP 2000 appliance. While reviewing our setup in iHealth, we received the following message: "Your hardware reached its End of Return to Manufacturing (EoRMA) date on April 1, 2025. Support options may be limited and an upgrade is recommended." As the platform is no longer under warranty and we’re running an older software version, we are planning to upgrade to the latest supported version on this hardware. Based on the compatibility matrix, it appears that BIG-IP 15.1.10.x is the latest version supported on the 2000 series. We understand that 15.1.x will reach End of Technical Support in December 2025, and we plan to use this upgrade as a short-term solution while we evaluate options for hardware replacement. Our questions are: Since we are out of warranty and do not currently have an active support contract, can we still upgrade to 15.1.10.x? If the device doesn’t have internet access, will collecting the license dossier and uploading it to the F5 licensing portal allow us to reactivate the existing license? Are there any limitations in upgrading or re-licensing in this scenario that we should be aware of? Any guidance or confirmation would be appreciated.F5 is not providing any console/Web Access.Software is corrupted. How to clean install its firmware?
My Failed F5 is not providing any console/Wwb Access after multiple tries. I think its software/Firmware is corrupted BIGIP 2000. How to resolve or clean install its firmware. Console access gives ambigous chars, numbering, how to clean install its firmware 13.0.0. while keeping in mind it would be hard reset first i think by any way because its not providing any web/console access. No screen buttons working and screen showing message only "F5 Networks incorporated".
Configuration of Pools VS LTM Policies and AWAF for Multiple Applications on Same Backend
I need your assistance and confirmation regarding a critical deployment involving F5 AWAF for internal applications. We have six internal applications accessible through the following URLs:https://gtt.XXX.ma:8443/gtt/;https://po.XXX.gov.ma:8443/po/;https://rpe.XXX.gov.ma/RPE/ https://sos.XXX.gov.ma/sos/;https://ant.XXX.gov.ma/ANT/;https://testcad.XXX.ma/testcad/. All these applications point to the same backend server at IP address 192.168.100.30. The DNS records for all of them resolve to the same IP address: 192.168.221.30. We are planning to configure two Virtual Servers using the same virtual IP address 192.168.200.20: One VS for applications running on port 443 ;One VS for applications running on port 8443: Each VS will have a dedicated LTM policy: One policy for the applications on port 443. Another policy for the applications on port 8443 . ach application must have its own dedicated AWAF (ASM) policy. Could you please confirm if this configuration is valid and supported by F5? Also we would like your recommendation on the following points: Should we configure a shared pool for all applications or a separate pool for each one?. Is the dual VS approach (with same IP but different ports) acceptable?. Is it the right approach to use LTM policies for routing requests and applying specific ASM policies per application? This deployment is critical and currently in preparation for production.
Questions about F5 BIG-IP Multi-Datacenter Configuration
We have an infrastructure with two datacenters (DC1 and DC2), each equipped with an F5 BIG-IP using the LTM module for DNS traffic load balancing to resolvers, and the Routing module to inject BGP routes to the Internet Gateways (IGW) for redundancy. Here’s our current setup (based on the attached diagram): Each DC has a BIG-IP connected to resolvers via virtual interfaces (VPI1 and VPI2). Routing tables indicate VPI1->DC1 and VPI2->DC2. Each DC has its own IGW for Internet connectivity. Question 1: Handling BIG-IP Failures If the BIG-IP in one datacenter (e.g., DC1) fails, will the DNS traffic destined for its resolvers be automatically redirected to DC2 via BGP? How can BGP be configured to ensure this? Is it feasible and recommended to create a HA Group including the BIG-IPs from both datacenters for automatic failover? What are the limitations or best practices for such a setup across remote sites? Question 2: IGW Redundancy Currently, each datacenter has its own IGW. We’d like to implement redundancy between the IGWs of the two DCs. Can a protocol like HSRP or VRRP be used to share a virtual IP address between the IGWs of the two datacenters? If so, how can the geographical distance be managed? If not, what are the alternatives to ensure effective IGW redundancy in a multi-datacenter environment? Question 3: BGP Optimization and Latency We use BGP to redirect traffic to the available datacenter in case of resolver failures. How can BGP be configured to minimize latency during this redirection? Are there specific techniques or configurations recommended by F5 to optimize this? Question 4: Alternatives to the DNS Module for Redundancy We are considering a solution like the DNS module (GSLB) to intelligently manage DNS traffic redirection between datacenters in case of failures. However, this could increase costs. Are there alternatives to the DNS module that would achieve this goal (intelligent redirection and inter-datacenter redundancy) while leveraging the existing LTM and Routing modules? For example, advanced BGP configurations or other built-in features of these modules? Thank you in advance for your advice and feedback!DNS Request to VS?
Hello, we found on our Firewall lots of DNS-Requests from the floating IP to some VS (with ASM-Policy). Now we want the Firewall to only allow DNS-Requests to the known DNS-Servers. Question: is this normal behaviour? The BIGIP has DNS-Resolver configured. Where can I check the Config-Utility? Thanks for any hint. Karl