Forum Discussion

laudo_359006's avatar
laudo_359006
Icon for Nimbostratus rankNimbostratus
Apr 18, 2018

Create second VIP for new application / not able to get to application

I have a F5 virtual appliance in AWS. Single nic. IT has a public IP and I am able to get to it using .

 

I create a VIP(10.0.1.44:443)-> Pool1 -> (node1,node2,node3(8080)) and am able to get to the application via VIP.

 

Now I have another application which listens on port 80 on a different node. I tried to create the following but am not able to get to the webserver

 

VIP(10.0.1.44:8443)-> Pool2 -> (web1(80))

 

What am I doing wrong as I am not able to get to web1? I am able to get to web1 directly to its private or public ip.

 

7 Replies

  • Without knowing more about the static config of BIG-IP, 8443 is used for BIG-IP management access (versions after 12.1). Public IP does not equal elastic IP so if we are just using the public DNS using NAT gateways, then you may be using the self IP for the applicaiton access. If we are talking about different IP's from what BIG-IP is using for it's self IP then I suspect traffic isn't making it to the BIG-IP interface.

     

    If you look at the VIP statistics tab, you'll see if any traffic is hitting that address. I suspect there may be some security group requirements that still need to be setup for 8443 from the elastic IP (you're using elastic for the public access correct?).

     

    Can you provide some more details around the IP configurations within BIG-IP and how the security groups are configured around the incoming traffic through the elastic IP that translates to your BIG-IP?

     

  • Yes tried to go for 2323 for the vip. Didn't work either

     

    So VIP(10.0.1.44:2323)-> Pool2 -> (node(80))

     

    Wasn't able to get to the node80

     

    The configuration is the default. Haven't touched it. Single nic on AWS.

     

  • Is 2323 open to the VIP in the security group? If it is, you should see some statistics on the VIP Statistic page.

     

    Default configs on AWS would not allow 8443 or 2323 in the security groups for your VIP network unless manually configured. Since they're non standard, can you make sure they're open for the security group assigned to that network or interface?

     

  • Yes security groups are open for 2323 and 8443. So thats not it.

     

    To be more precise, AWS SG are open for 2323 and 8443. The weird thing is even internally, I get blocked when doing a curl to http://10.0.1.44:2323

     

    So you are confirming that I should be able to create 1 VIP with multiple ports and pools assigned to it correct?

     

  • Unless you were using the PerApp VE license and went over the 1 virtual IP and 3 virtual server limit, yes this works fine.

     

    This is how many applications work when using a 443 application port and alternate port for management or other features such as API access.

     

    Did you see any traffic hit the VIP when you used curl? Are you using a jump box within the AWS 10.0.1.44 network? If the traffic is getting to BIG-IP, a tcp dump may help you identify where the traffic is terminating. You should see a tcp handshake on 10.0.1.44:2323 and tls negotiation. You should also see the same data for the BIG-IP to node just without the tls negotiation.

     

    I had this exact config stood up last week in AWS in a VPC and it does work. I however use a AWS workspace to access the application VIP to keep everything self contained.

     

    Breaking the troubleshooting down in a similar fashion will help you isolate out the issue.

     

    1. If you can get to 10.0.1.44:443 from your source, then 2323 will work if open. You can verify this with TCP dump or VIP statistics
    2. Verify the VIP is green meaning your health monitor to your node is working and it's accessible to BIG-IP. You can verify this by logging into your BIG-IP and using curl from the CLI. Or even just a ping if ICMP is open within the sec group (all security groups include a all access for anything residing in that group)
    3. If you're connection is resetting instead of timing out, check your routing to ensure the application server is routing back through BIG-IP or you planned for async routing (SNAT Poo within the VIP).