Cannot ping external interface

Forums Technical Forums
1

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 simple (and probably stupid question)

On our LAN I have been able to set one device with a management interface, a virtual server and all the hosts and nodes are connecting fine. This is in a typical round robin setup.

The thing I cannot figure out is the external port and address.

For brevities sake and simplicity I have one physical interface connected directly to the gateway provided by our ISP and we have a block of static public IPs provided. I have assigned , or want to assign, one of the spare IP address to this interface. This is method we have with our other (non F5 firewalls) and it works, but not here.

I have created a VLAN called external , set it to untagged and assigned the interface connected to the gateway to this VLAN.

I then assigned that VLAN to my VirtualServer. However I cannot ping or reach the external IP address in any fashion and I am not sure why

2

Hey,
Are you pinging the self ip? if so, look at port lockdown that might be the issue allow default should include icmp.
If you are pinging a virtual IP, make sure that the pool members you have there can even respond to icmp and that the virutal IP is available (green).

3

Hello, a couple things here:

if you assign a VLAN to a Virtual Server, it will only accept traffic coming from that VLAN.

Given that you configured the VLAN as native (untagged) on a specific interface (let’s say it’s 1.1),  this means that only traffic coming from interface 1.1 will be able to reach the virtual server IP address.

With default configuration, the VS virtual address will respond to icmp queries when the status of the VS is green (available).

F5 will use the MAC address of your EXTERNAL vlan whe responding to ARP requests for virtual address IP.

Then, you have the self IPs. They are the IP addresses that F5 uses to determine connected interfaces and for routing. They are also used for monitoring probes, and sometimes for NAT if you use automap option.

With default configuration, these IP addresses reject all packets. This is a standard security procedure, because you usually don’t want your users (or other appliances on the network) to be able to connect to the BIG-IP unit on a traffic interface.

If you need to enable some protocols (let’s say, BGP for routing , or ICMP if you need it, or all the HA services to set up a cluster) then you’ll need to change the self-ip port lockdown behavior from “Allow None” to the option that suits you best. You can change it to “custom” and only allow things you want, or use any pre-configured profile (like “allow default” is commonly used for HA).

Check this → myF5

4

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.

5

OK, wow, its very obvious I don’t know what I am doing.

I did check the lockdown, thanks for that advice, and set it to default. I see that it allows 443 through, not port 80 which is fine.

However, on the public facing side, it is working, but it is presenting the BIG-IP Management LogIn page, not the servers in the pool . How this is works I do not know as they are on their own VLAN which is ostensibly completely separate from the pool, any routing table and so on.

When I first got the devices I spent some time following a tutorial to set this up and it worked just fine. The only difference was the external network was connected to an internal LAN so that I could understand how this worked and work it did.  The webserver are on their own DMZ VLAN and all worked as expected .  I had not set up any self IPs . However as soon as I changed the IP of the virtual server to a different IP and network, I have not been able to get this to connect and it has been days of trying to determine what the BiGIP wants and I have probably completely messed up the configuration in attempting to get this to work

6

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).

7

image_344246.png
image_344246.png1037×792 56.9 KB

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)

8

One thing is the self-ip address, one other thing is the virtual server.

Self-ip address belong to .. “self”, which is F5 indeed, so if you connect to them you should expect F5 to respond with the F5 management interface! :slight_smile:

“How this works” is tricky - as f5 keeps separate routing table for data plane and management plane. But essentially, allowing access to a self-ip is opening the management plane access through the network (again, there’s a reason why it’s locked down by default).

If you need F5 to act as a full-proxy (hey, that’s his job!) and publish a web server, you need to set up a virtual server. All of the objects you need to do this are found in the “traffic management” menu. This includes your pool and all the other stuff. 
Check my other comment to have a better understanding on what you need to connect F5 to the network, and once that is set up and ready, you can create services “on top” of the deployment you just set up.

Understanding how this works is part of the fun :slight_smile: but feel free to ask if you still have any doubt

9

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.

10

Hello @peeryog

Thank you for joining our community!

Noticed there was a good amount of assistance from our community. I wanted to encourage you provide an update if it has been solved to mark the solution or provide additional information if you are still needing assistance.

-Melissa