Forum Discussion
NimbostratusCannot 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 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
8 Replies
ShyyCirrus
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).- CA_Valli
MVP
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 -> https://my.f5.com/manage/s/article/K17333
peeryogOK, 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
- CA_Valli
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! :)
"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 :) but feel free to ask if you still have any doubt
- peeryog
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
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
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)
