Connections reset (os error 10054) on custom ports since recent Quest firmware / Windows updates

[agarwalviraj]

Description

Gnirehtet previously worked correctly for streaming between a Meta Quest 3 headset and a Windows 11 PC, including applications that use custom TCP ports such as Virtual Desktop.

Since early November 2025, all connections to non-HTTPS ports (for example, TCP 38811) are being immediately reset by the remote host. Standard ports such as 443 continue to work normally.

The issue appears suddenly after months of stable use with no configuration changes.

---

Expected behavior

Connections to any remote host and port should behave the same way as standard HTTPS traffic through the Gnirehtet relay, without early resets.

---

Actual behavior

Connections open and then close immediately with the following error:

ERROR TcpConnection: 10.0.0.2:<random> -> 40.89.161.236:38811 Cannot read: [ConnectionReset]
An existing connection was forcibly closed by the remote host. (os error 10054)

At the same time, Virtual Desktop reports:

Remote routing: possible double NAT

Connections on port 443 (HTTPS) continue to work normally.

---

Environment

Component | Version / Notes -- | -- Gnirehtet | v2.5 (also tested v2.6) Device | Meta Quest 3 (Android 12 base) PC OS | Windows 11 (latest updates) Java Version | 17 (tested both Java and Rust builds) ADB Version | 1.0.41 Connection | USB tethered Symptom | ConnectionReset on custom TCP ports, “possible double NAT” message

---

Reproduction steps

1. Connect Quest 3 via USB and enable Developer Mode.

2. Run:

   gnirehtet run
   

3. Observe log output when connecting to a non-HTTPS remote host, e.g.:

   10.0.0.2:34173 -> 40.89.161.236:38811
   Cannot read: [ConnectionReset]
   

4. Confirm that connections on port 443 work normally:

   10.0.0.2:56202 -> 57.144.212.141:443 Open
   

---

Troubleshooting attempted

• Set MTU to 1400 on gnirehtet interface

• Disabled Windows Firewall and antivirus

• Tested both Rust (gnirehtet.exe) and Java (gnirehtet.jar) builds

• Tried --relay-host and manual relay mode

• Verified the target port is reachable from the PC (Test-NetConnection ... -Port 38811)

• Tested reverse mode (-r)

• Issue persists only for non-HTTPS ports

---

Additional observations

• The setup worked reliably before recent Quest firmware or Windows updates.

• The problem began appearing in November 2025.

• Behavior suggests a change in Gnirehtet’s NAT or relay handling of TCP streams.

• The 10054 reset happens almost immediately after SYN/ACK.

• Java version occasionally works better but not consistently.

---

Possible cause

• A change in Meta’s firmware VPNService or MTU handling.

• Stricter TCP or socket handling in newer Rust builds of Gnirehtet.

• Windows update introducing new packet inspection or filtering rules.

• Relay may now close sockets prematurely on custom ports.

---

Request

Please confirm whether there have been any recent changes to the NAT or relay code path since v2.5.
If possible, provide a diagnostic or test build with more detailed TCP teardown logs for non-443 connections.

This regression currently prevents use of certain applications (like Virtual Desktop) through Gnirehtet, even though they worked fine in earlier versions.

---

Example log excerpt

2025-11-09 13:58:41.649 ERROR TcpConnection: 10.0.0.2:34173 -> 40.89.161.236:38811 Cannot read: [ConnectionReset]
2025-11-09 13:58:41.649 INFO TcpConnection: 10.0.0.2:34173 -> 40.89.161.236:38811 Close
2025-11-09 13:58:42.121 INFO TcpConnection: 10.0.0.2:56212 -> 57.144.212.141:443 Open

[ryanworthington211-dotcom]

This error is happening to my RT-RP CMD line and will not hold a connection for more than a second before being disconnected. It is a cycle of connecting then disconnecting and error "2026-01-20 21:52:53.198 ERROR TcpConnection: 10.0.0.2:52142 -> 157.240.245.13:443 Cannot read: [ConnectionReset] An existing connection was forcibly closed by the remote host. (os error 10054)
2026-01-20 21:52:53.198 INFO TcpConnection: 10.0.0.2:52142 -> 157.240.245.13:443 Close"