SSH Proxy Problem: Real Server Auth
Hi, while playing around with the SSH proxy feature, I'm encountering issues with the validation of the Real Server Auth key. I've configured the profile as described in https://support.f5.com/kb/en-us/products/big-ip-afm/manuals/product/network-firewall-policies-implementations-12-1-0/13.html. Unfortunately I got an error message in /var/log/sshplugin: err : SSHPLUGIN: sshplugin_2|SSHPlugin|ssh_setup_serverside|Core|the backend ssh server does not have a public key that matches the configuration! (0) Erroring out of this connection. I've checked and doublechecked the host key using ssh-keyscan and copied the key string into the field "Real Server Auth". The format of the key looks exactly like the one from the manual, except that my key is a one-liner instead of the block view in the manual. The manual shows the key in block view AAAAB3NzaC1yc2EAAAADAQABAAABAQCziS6yavPpFuRjLP9hzRiEBcVgLDynoW qNMuwCrOREkSiDqWqFRrydFCGy6Z1WwwJuDMIw5h3sIuqtOo78zd6pBabXpj0Q LUyLtGx80Oe3vInpwxvG2/YX9KaGjofkasZJ+tOqoOe5QscnUYr7Iw6CEuo2dB VIZyL/o1IyTvDfL8+yXO4vPzadmL0gvV1F56feRVsCF0HUrhWwdrQ6CpIpX6ac sY0HayrhOGPmVF4qRz7fLySHJ5XQz5IKXJRNHJEbXx2tiV1TuQlhz8gOMqMp2I iSqyKDcUTk2Oy0fPYkNAWPlifq7GplYkit85EL5UCgtHf595rqibOQJWFAAzHF while mine looks like AAAAB3NzaC1yc2EAAAADAQABAAABAQCziS6yavPpFuRjLP9hzRiEBcVgLDynoWqNMuwCrOREkSiDqWqFRrydFCGy6Z1WwwJuDMIw5h3sIuqtOo78zd6pBabXpj0QLUyLtGx80Oe3vInpwxvG2/YX9KaGjofkasZJ+tOqoOe5QscnUYr7Iw6CEuo2dBVIZyL/o1IyTvDfL8+yXO4vPzadmL0gvV1F56feRVsCF0HUrhWwdrQ6CpIpX6acsY0HayrhOGPmVF4qRz7fLySHJ5XQz5IKXJRNHJEbXx2tiV1TuQlhz8gOMqMp2IiSqyKDcUTk2Oy0fPYkNAWPlifq7GplYkit85EL5UCgtHf595rqibOQJWFAAzHF Hopefully this doesn't make a difference. I even don't know how to turn on debug logging for sshplugin. Maybe this would help. Any ideas? Greets, svs
using '--resolve' in the pool monitor health check
Hello, I am checking if it's possible to add the option '--resolve' in the health check monitor and avoid using a custom monitor (which consumes too much memory). For example: curl -kvs https://some_site_in_the_internet.com/ready --resolve some_site_in_the_internet.com:443:196.196.12.12 I know you can use curl -kvs https://196.196.12.12/ready --header "host: some_site_in_the_internet.com" But the path to the servers has some TLS requirements that' does not work. Any ideas are welcome Thanks
HA between rSeries tenant and iSeries appliance.
According to F5 documentation, the BIG-IP system supports either homogeneous or heterogeneous hardware platforms within a device group. I want to confirm if anyone has tried to put rSeries tenants and iSeries appliances in the same cluster? Obviously, I understand they will need to be on same version and of course vlans will be same on both. If you have tried this before, what were your challenges and how did you overcome them? I am considering this approach because it makes migration easier and seamless.
Horizon View iApp - Big-IP 17.5
I have a client deploying an r4650 pair. The plan is for it to handle Exchange, LDAPS & Horizon View. I’m in the process of initial setup on the pair of boxes now. It’s been a long time since I've deployed Horizon View on F5. I see that the iApp is still maintained so yay! Question: is the current 1.5.9 version of the iApp supported in Big-IP 17.5? The KB article states 17.1 but the article hasn’t been updated in a while. F5 recommends the latest version of 17.5 but I don't want to hit any snags as we deploy. Thanks in advance, MattMgmt Interface Shows Up as TMM
So I have an F5-VE I'm working on that the Mgmt doesn't ping or accept SNMP requests. I opened a case with F5 and they say my 1.0 interface and my Mgmt interface has the same MAC. tmsh show sys mac-address | grep interface 00:50:XX:XX:XX:XX net interface 1.2 mac-address 00:50:XX:XX:XX:XX net interface 1.1 mac-address 00:50:XX:82:b5:aa net interface mgmt mac-address 00:50:XX:82:b5:aa net interface 1.0 mac-address 00:50:XX:XX:XX:XX net interface 1.3 mac-address I have never seen anything like this. Has anyone ever seen anything like this and what did you do to fix? My plan is to remove the 1.0 boot and see what happens. Add it back if needed. From all the documents I've looked at when that interfaces is created in VMware it should make a TMM interface is should make the Mgmt interface in the VLAN we specify when building it from the OVA.
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!
