Forum Discussion
Trouble applying GoDaddy certificate to a virtual server
- 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.
- 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. - 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 🙂 - 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.
Hi Shadow ,
Make sure that you attached the correct intermediate certificate in Chain section.
Take a packet capture for a sample client ip and share it here or private if this available with you
I provided it in my response to F5_Design_Engineer.
- 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. - 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 🙂- ShadowJun 12, 2023Cirrus
I'm not sure where the 1212 is coming from. I did check against an existing environment that is working and I see the same 1212 without a reset.
The only difference is this environment is internal and the non-working site is in the DMZ. I did verify that in the TCP profile, the MSS setting is 1460 across all environments and the MTU is 1500 across all VLANS.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com