For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

peeryog's avatar
peeryog
Icon for Nimbostratus rankNimbostratus
Oct 30, 2025

Cannot ping external interface

Hi All, first post here, first time F5 devices and a complete novice.  I have a couple of BIG-IP devices and the luxury to play and learn before we go live.  I have one I am sure is going to be a si...
deployment
peeryog's avatar
peeryog
Icon for Nimbostratus rankNimbostratus
Nov 06, 2025

Hi All

 

Thanks for the suggestions.  I can provide some further insight.

My external facing interface will now happily accept http requests.  Using curl I will get a response and a handshake but then it will immediately shutdown the connection with an error 52 Empty reply from server. I am assuming this means external requests are reaching the virtual server but the server cannot connect to the pool hence the response.

 

The pool is running and has active health monitors to the nodes , including an HTTP monitor that is green.  tcpdump shows the monitors working and gettng the appropriate response from the webservers on the nodes.

 

So it seems the virtual server is not routing to the pool, though the pool shows as available.

 

The pool is using the internal network 10.1.0.0 . The external Virtual Server has the public IP address .  The external VLAN does NOT have any self-IPs since  A) i only have one public facing IP which I have assigned to the virtual server and B) i cannot tell from the conflicting information if self-ips are required or not. 

CA_Valli's avatar
CA_Valli
Icon for MVP rankMVP
Nov 07, 2025

I still see a lot of confusion, let me help you out with this. 

Let's start from connecting F5 to your network. You have one internal VLAN (10.1.0.0) and one external VLAN, correct? And you mentioned that the VLANs are untagged, so you have 2 physical interfaces as well, correct? 

For every network segment where F5 talks, it needs a self-ip address. This is pretty much to let your gateway and your LAN know you exist and to provide a MAC address for layer 2 operation. 2 VLANS means 2 self IP addresses in this case. 

If you want the self-ip's to respond to ICMP probes (ping), then you need to tune the self-ip lockdown behavior. 

Last thing you need is a default route. In every deployment I ran, this is configured to point to the Gateway of the external VLAN so that packets destined to my client IP addresses are routed back where they came from. 

 

Now, let's configure a virtual server. You create nodes, you configure a load balancing pool, and you make sure F5 can talk with them (you already mentioned monitor's green, so great!)

Next step is to set up the VIP responder. It can have any IP address and it's not restricted to your VLANs! Altough it's common practice to assignn an IP in the same network as your external interface, just because it's easier to route. But don't worry - if you want a public IP to be on F5 you can totally do it withous having to use public addressing on the connected LANs. 

When F5 receives packets for that specific IP address AND port AND on the external VLAN since you configured such interaction (it has to fully match the virtual server responder configuration), it will accept the packet. There's built-in counters in the GUI that help you understand if this is happening. 

Now the F5 makes a load balancing decision and forwards the packet to the servers. 

You said that from pcap files you see this is happening, and this is great, but .. do you also see response from servers? 

My bet is that the server is trying to send the packet back to the original source, instead of routing it back to F5. An easy way to force this interaction is changing NAT configuration on the Virtual Server to "auto map". This means that when the packet leaves F5 on the server-side connection, F5 changes the source IP address to one of his own self-ip's (specifically, the one of the interface that was used to route the packet out). 

  • CA_Valli's avatar
    CA_Valli
    Icon for MVP rankMVP
    Nov 07, 2025

     

    Here's the most baic scenario. You don't really need to have separate VLANs for FE and BE if you configure routing well enough. 

    Keep in mind that if BackEnd servers (centos) receive a packet with source 2.0.2.5 , there's a chance response may not be routed back the same way (and firewall may block out of state packets) 

    • peeryog's avatar
      peeryog
      Icon for Nimbostratus rankNimbostratus
      Nov 09, 2025

      I really appreciate the input.  I am still stuck but I can engage support tomorrow since this is all for initial testing and setup and i just want to make sure it is configured correctly. Just to reiterate. 

      1. I have two web servers. They are 172.16.0.11 and 172.16.0.11.
      2. I have an internal VLAN. This is tagged. Why is it tagged?  The two webservers have two NICS. One NIC links to our internal network to retrieve data. The second NIC is attached to the F5 and is considered the DMZ VLAN and this is the same also the internal VLAN on the F5. This internal VLAN is active on port 1.6
      3. The internal VLAN has a static self IP of 172.16.0.8. This is also the gateway assigned to the NICs on the web servers .
      4. The web services on the web server will only listen on the internal VLAN
      5. Monitors for icmp and http are enabled on the Virtual Server and these are green for the nodes and the pool .  All seems to be good there.
      6. The virtual server has AutoMap enabled.
      7. If I ssh into the management port on the tenant, I can curl to either of the webservers and get the appropriate response. 
      8. If I ssh into the management port on the tenant, I can curl to to the static self IP (172.16.0.8) on the VLAN  webservers and get connection refused. This I suspect is normal but what do I know.
      9. I did try adding a floating self IP to the internal VLAN but it made no difference so I removed it. To be honest the amount of information on the floating IP requirements seems to conflict, so I don't know if I need it or not. I did not have it in the original where the system was working.
      10. When I initially set this up , the destination IP address of the virtual server was on our internal network, say 10.1.1.50.  At this point it worked fine.  Anyone on our internal network could be served by the web servers
      11. I then physically connected the external interface (1.7) directly to our ISP gateway and assigned it one our precious few public IPs.
      12. From this point on I cannot get a response.
      13. From an external source I can ping the virtual server. I know this is correct (just to ensure I did not have the IP address assigned elsewhere) by physically disconnecting the F5 interface and the ping is lost.
      14. From an external source I can curl the external address. It does respond but then the connection is reset with an error 56 .

       

      So it seems to me to be a simple routing issue that I am missing. Everything appears to be OK, the virtual server is ready and enabled , all the servers and ports are ready as well.  I have no Routes in the config. If I try to add a route that I think I need , the utility tells me that the route is already implicit in the settings I have, so that also seems to be correct.