Forum Discussion

Shadow's avatar
Shadow
Icon for Cirrus rankCirrus
Jun 06, 2023

Trouble applying GoDaddy certificate to a virtual server

I have created a few virtual servers and applied certs. They work just fine because they are using our internal CA. I have one now that uses a GoDaddy cert. I was provided a GoDaddy pfx file. I impo...
application delivery
certificate
godaddy
ssl
  • Paulius's avatar
    Paulius
    Jun 09, 2023

    Shadow it looks like F5_Design_Engineer is on the same track as me. The F5 is receiving a RST from the backend between it and the server so asymmetric routing or the destination pool member itself.

  • Mohamed_Ahmed_Kansoh's avatar
    Mohamed_Ahmed_Kansoh
    Jun 09, 2023

    Hi Shadow , 

    Now , You Must take a packet capture in both sides ( Client and Server ) sides , I feel that the Backend servers that Reset this traffic not Bigip itself the ssl negotiations went correct from the Client side. 

    Bigip took The client Application Data and forwarded it to Backend server , so most properly the backend server itself restted this traffic for various reasons need to be checked furtherly.

  • Mohamed_Ahmed_Kansoh's avatar
    Mohamed_Ahmed_Kansoh
    Jun 09, 2023

    Hi Shadow , 
    Forget about my last reply , as I saw you captured the Full stream of ( Client and server side ). 

    It's very clear that Rest comes from IPs ( 173.235.20.160 & 161  ) which your Backend servers. 

    I see that your Servers couldn't able to establish 3-way handshake with Bigip , Servers reject the First SYN Packet from Bigip , but the most confusing me how the https health monitor marks your pool as up and at the same time bigip can't establish with servers 3-way handshake on real data traffic. 

    >>> I found something strange to me : 

    Do you see MSS value ? it's 1212 which not the standard , it's very very important to check your backend servers's MTU and the MTU in Bigip server side must be compatable with your backend servers that's why your servers Reset this connections , make sure that MTU matches each side ( Bigip server side and Backend servers ) 

    I will tell you another idea >>> What about take a packet capture for your heath monitor to see while monitoring Bigip sends monitor packet with this MSS = 1212 or not as from your pool configuration I see the Https monitor marks your Backend servers Up and Can establish 3-way handshake correct. 
    So we need to compare between Client traffic on server side and Health monitor traffic on server side as well. 
    Concentrate more in the server side not ssl certificates.

    I will be waiting your results 🙂 

  • Shadow's avatar
    Shadow
    Jun 23, 2023

    I have a ticket open with support and they have confirmed it is not a GoDaddy issue, but rather the backend server. Resets are coming after the redirection. 

     

F5_Design_Engineer's avatar
F5_Design_Engineer
Icon for MVP rankMVP

Hi  Shadow , 

Could you please share the output of your VIP and the SSL profile using tmsh commands as follows:

in tmsh mode:

 list ltm virtual NAME_OF-YOUR_VIP all-properties

list ltm profile client-ssl NAME_OF-YOUR_PROFILE all-properties

I am suspecting if you are using SNAT or Automap for address translation or port translation or not, cauing any sort of assymentric routing.

As I dont have your VIP configuration i cannot check if you have translate-address disabled and translate-port disabled ?

Please read this 

K79443053: Address translation and port translation behavior on a standard virtual server

https://support.f5.com/csp/article/K79443053 

as if you are talking about asymetric routing 

https://support.f5.com/csp/article/K13558 

K13558: Allowing asymmetrically routed connections across multiple VLANs (11.x - 16.x)

then you will need to fix your TCP profiles.

 If you are using any iRules we can tshoot ,only when you will provide your VIP and SSL profile configurations.

 

 

HTH

Best Regards,

F5 Design Engineer

  • F5_Design_Engineer's avatar
    F5_Design_Engineer
    Icon for MVP rankMVP
    Jun 09, 2023

    Hi ,

     

    This infomation looks but do not provide any details to the error you care facing.

     

    Can you run this tcpdump and share the pcap:

     

    You need to take a tcpdump on the BigIP to see where the reset is being generated from, and why.

    For onscreens display only

    tcpdump -n -v -s0 -i0.0:nnnp host <vip IP> and port 443

    Also, try running a curl command to the VIP

    curl -kv https://<vip fqdn>/ --resolve <vip fqdn>:443:<vip IP>

    Try this tcpdump and share the output to be caputed in a PCAP file :

    tcpdump -vvv -s0 -nni 0.0:nnnp host <vip IP> and port 443 -w /var/tmp/`/bin/hostname`_`date +%Y-%m-%d--%H%m%S`-DADDY-SSL-ISSUE.pcap

     

    Best Regards,

    F5 Design Engineer