OVH VPS – source-dependent TCP connectivity unresolved for a week – CS16656385

Bare Metal et VPS
1

Hello,

I am looking for assistance with an ongoing source-dependent network connectivity problem affecting my OVHcloud VPS.

Support ticket: CS16656385

The issue has now been ongoing for approximately one week and continues to affect a significant percentage of my production users across different regions and ISPs.

The problem started immediately after migrating the services to OVHcloud.

The issue affects both HTTPS web traffic and the game server TCP connection.

The behaviour is source-dependent:

  • affected users may have difficulty opening the website over HTTPS, with pages loading partially, stalling or timing out;
  • affected users can successfully establish a TCP connection to the game server, but after approximately 1–3 seconds ACK/data traffic may stall or drop and retransmissions occur;
  • unaffected users can access both services normally at the same time;
  • affected users can connect normally when their game traffic is routed through an external TCP proxy to the exact same OVH VPS.

Extensive diagnostics have already been supplied to OVH support, including MTRs, PCAPs, confirmed affected source IPs, MTU/PMTUD testing, direct connection testing and external proxy comparison testing.

We also tested an affected client by manually reducing its MTU to 1492 and even 1400. This made no difference, so the problem does not appear to be a simple client-side MTU/PMTUD issue.

Because the issue affects both HTTPS traffic and the game server TCP connection from the same affected source networks, this does not appear to be specific to Apache, the website application, or the game server application.

OVH support has confirmed that CS16656385 has been escalated to the internal Network team, and that the Network team is still investigating it.

However, after approximately one week, I still have no technical findings or root cause, while the production issue remains active.

I am not asking the community to repeat basic firewall or server troubleshooting. Those areas have already been extensively tested.

I am mainly hoping that someone from OVHcloud can help follow up / relaunch the team responsible for CS16656385 and help move the existing investigation forward.

If any OVHcloud staff member sees this, I would greatly appreciate a review of the current status of CS16656385.

Thank you.

2

Hello @nori4z

Call OVH customer support at +33 9 72 10 10 07.
Preferably between 8 a.m. and 9 a.m. in the morning, or around 3 p.m. there is less waiting.

Or already now on Twitter @ovh_support_fr or #OVHcloudsupport

image
image676×336 118 KB

3

Hi @nori4z

You've done a very thorough diagnosis and it's clear that you've ruled out many things. Precisely because of that, I have a couple of questions that might help narrow down the problem even further:

  1. Have you been able to check whether the problem persists if you change the listening port of your services?
  2. Have you tried running the tests with a VPS in another region?
  3. Have you looked at whether the problem aligns with any time pattern or traffic spikes? Sometimes network issues depend on the source, but also on the timing.
  4. Have you been able to confirm whether the affected users share anything beyond the ISP, or if they are behind a CGNAT?

It's not to doubt your analysis; on the contrary, it's in case any of these tests can give a new clue to the OVH Networks team. Sometimes a seemingly small piece of data makes the difference :wink:

We'll stay in touch,
Sergio Turpín

4

Hi Sergio, thank you for taking the time to look into this.

Regarding your questions:

1. Different ports

The issue does not appear to be limited to a single listening port or application.

Affected users experience problems with both:

  • the game server TCP connection; and
  • the website over HTTPS.

The website may begin loading and then stall/time out, while the game TCP connection can establish successfully and then stall or disconnect shortly afterwards.

This is one of the reasons I do not believe the issue is specific to one game port, Apache, or one application.

2. Testing another VPS / region

I have not tested this on another OVH VPS because doing so would require ordering and paying for an additional VPS and then migrating/configuring the services purely for diagnostic purposes.

I do not think it would be reasonable for me to purchase additional hosting simply to investigate an issue that started immediately after moving my production services to OVHcloud.

However, if OVHcloud can provide a temporary test VPS, temporary IP, or migrate the existing VPS to another physical host/network segment for diagnostic purposes, I would absolutely be willing to deploy a test copy of the game server and ask affected users to test it.

In fact, I think testing on another OVH host/network segment would be particularly useful:

same application + same affected users + different OVH network path / host

If the problem disappears, that would provide a very strong indication that the issue is related to the current infrastructure or network path rather than the application.

3. Time of day / traffic pattern

So far I have not observed any clear correlation with a particular time of day or traffic peak.

Affected users can experience the problem while other users are connected normally at exactly the same time.

The issue therefore appears much more dependent on the source network/path than on server load or time of day.

4. ISP / CGNAT / common characteristics

The affected users are located in different regions and use different ISPs, so there is no single provider common to all of them.

I have not confirmed whether every affected user is behind CGNAT. I can check this on a small number of confirmed affected users if you believe it would materially help the investigation, but I cannot realistically ask a large percentage of production users to perform repeated network diagnostics.

The strongest diagnostic observation remains unchanged:

an affected client has problems on the direct path to the OVH VPS, while routing that same client’s traffic through an external TCP proxy to the exact same OVH VPS makes the connection work normally.

OVH support has also confirmed that the TCP handshake completes normally for affected connections, but afterwards ACK/data traffic from certain source networks begins to stall/drop and retransmissions occur.

We also tested MTU/PMTUD on a confirmed affected user. Reducing the client MTU first to 1492 and then to 1400 made no difference, so a simple MTU/PMTUD issue does not appear to explain the behaviour.

I am happy to perform additional targeted tests if they can genuinely help isolate the fault, especially if OVH can provide a temporary alternative host/network path for comparison.

Thank you again for looking into this.

5

Hi @nori4z

Thank you for the very detailed response. From what you explained it’s clear that the problem is in the OVHcloud network, not in your stack. The proxy information is important… same client, same VPS, but operating through an external intermediary. That points directly to a specific network route or segment that is failing for certain origins.

Since you have already provided MTR, PCAP and all diagnostics to ticket CS16656385, the next step is for the OVHcloud Network team to review that information and act. There isn’t much more you can do from your side.

Thank you for the detailed information :folded_hands:

I hope they give you a solution soon. Keep us informed.
Sergio Turpín

6

Thank you Sergio, I really appreciate you taking the time to review all of this.

Yes, at this point I also believe there is very little more that can reasonably be tested from my side.

The correct ticket number is CS16656385.

I will keep this thread updated as soon as OVHcloud Network Engineering provides any concrete findings or a resolution.

Thanks again for your help.