iApp - View

Hi TD-Roy,

By default the BIGIP vs should respond to pings, do you have a firewall or any other network devices that may be blocking traffic to your View VS address?

Hi Greg,

Thank you for a quick response.

I am able to ping every other devices on the same network as the LTM VS address. So I dont believe this is the case.

Here is my config on the iAPP in case it helps: Basic Config Mode SSL Bridging Default SSL certs (i know I know) Yes, PCOIP connections through BIGIP No proxied by View Server 10...x network All VLANs support PCoIP No USB Redirection VS IP : 10... Port 443 FQDN: f5.name.local Servers in the Pool: Both IP addresses for View and/or Connection servers Port 443 (have changed this up to test) Health Monitor: https

I would setup a tcpdump on your BIGIP to verify traffic is being passed to your View virtual server. Something like tcpdump -i 0.0 host "vs address" and port 443

I dont think its a matter of traffic going from the BIGIP to the View Server; the traffic is not even reaching the BIGIP. If I go to statistics in the LTM, there are 0 (none) sent or received packets.

I would use the tcpdump to verify web requests (443 traffic) from your View client is reaching your BIGIP virtual server address. Also, is your View security or connection server pool appearing healthy?

Using: tcpdump host 10... for the VS address after running the View client until fail, this is what I receive:

09:48:10.867846 arp who-has f5.name.local (broadcast) tell "gateway address" "" ""

Over and over until it fails.

Does this mean that the VS address is seeing the attempted connection but cannot forward?

And yes my View environment is green. Im just looking to test actual passthrough from the F5 to the Sec or Connection servers. Dont need optimization etc just yet.

You should see something like: 10:31:09.560937 IP 10.133.100.229.51297 > 10.133.100.147.https: S 1809782882:1809782882(0) win 8192

Where 10.133.100.229 is going to be your view clients address and 10.133.100.147 is going to be the virtual address on your BIGIP. If you do not see the initial syn request then the client address and request is most likely being blocked by another device, a possible routing issue for the vs address being used, or your BIGIP is not correctly configured for the vlan and vs ip address being used. However, if other ip addresses on the same network are working, then it is probably not the last two mentioned.

Also, what is f5.name.local, is it by chance the View vs address being used? you can shut off name resolves on your tcpdump with the -n switch.

In the iAPP configuration it asks for an FQDN for the VS address -> f5.name.local

I dont believe its a routing issue as its on the same subnet and there is no firewall/any device that would block it at this point.

There must be something on the F5 that is not configured correctly that is not allowing the traffic to reach it. Currently, since we are only testing, we have all interfaces on the same vlan. Would this cause an issue? Im going to try to move the mgmt interface to a different subnet and see what is working/not working.

Are you able to ping the SelfIP address on the 10... subnet? Can you from and SSH session of from the console of the BIG-IP, ping the client address you are trying to connect from? The Management interface can be on the same PortGroup and even on the same 802.1q VLAN but must be on a different subnet. In my testing environment, I often setup my BIG-IP management on the same PortGroup as the interface attached to the Internal VLAN, but I assign the mgmt a 192.168.x.x/24 address and the internal a 10.x.x.x/24 address.

Hi ppindell,

Thank you for the response. From the BIGIP console, I can ping both my View Security Servers and the connection servers.I can ping the management IP from it, but cannot ping the virtual server address.

I dont have any SelfIPs defined, should I?

Also, now that I rebuilt the system, I have the Mgmt IP on lets say s 192.x.x.x address. I have my HA network on an isolated network, and I have both internal / external networks on the 10.x subnet.