Fixing network problems of WSL + VPN/TUN

Google Antigravity is an agent—based development platform that implements the Agent-First IDE paradigm. The architecture of the platform assumes a high degree of connectivity between local execution agents (in the WSL environment) and cloud-based orchestration services. When using L3 tunnels (sing-tun, Hiddify) and WSL virtualization, specific problems of traffic encapsulation and routing arise.

You may ask, "What does Google Antigravity have to do with it?"
I will answer: "Because when using it from the territory of the Russian Federation, you can catch problems with the network connection."

This guide describes a methodology for locating and eliminating network failures based on the analysis of dumps and interface configurations.

1. Collection and analysis of primary diagnostic data

To identify network problems, use the built-in log collection tool. In the IDE command palette, run:
Antigravity: Download Antigravity Diagnostics

Important note: The process of data collection and report generation can take a considerable amount of time (up to several minutes). Upon completion of the operation, the IDE initiates a system dialog for saving the file (Save As) with the default name Antigravity-diagnostics.txt.

Critical indicators in the file Antigravity-diagnostics.txt:

• TLS handshake timeout: Error at the stage of agreeing on encryption parameters. Indicates the loss of data packets (Certificate) due to fragmentation issues.
• Connection reset by peer (ECONNRESET): Forced termination of a TCP session by an intermediate node or the host's firewall.
• Model not found (HTTP 404/500 for 1008/1018 resources): Inability to load configuration manifests of multimodal models due to blocking of the antigravity-unleash.goog endpoints.
• Timed out while waiting for response: Exceeding the waiting time limit for a response from the gRPC interfaces of the cloud backend.

2. Verification of network connectivity in the WSL environment

Since the control processes (Language Server, PID 700) operate inside the WSL, diagnostics must be performed in the context of this subsystem.

Testing TLS handshake

Emulation of an agent registration request with extended output:

curl -k -v https://antigravity-unleash.goog/api/client/register

Interpretation: Stopping the process after receiving Server hello (2) indicates that it is impossible to receive packets larger than the current Path MTU.

Audit of MTU parameters (Maximum Transmission Unit)

The discrepancy in MTU sizes on virtual and physical interfaces is the most likely cause of data loss during encapsulation.

Host (Windows PowerShell):
netsh interface ipv4 show subinterfaces

Example of output with an anomaly (Jumbo Frames on a tunnel):

       MTU MediaSenseState Received Byte Sent Byte Interface
----------  ---------------  ------------  ------------  -------------
      9000                1      25519176      20676185  tun0
      1500                1    1052027165     317349294  Ethernet 3

Special attention: the presence of MTU 9000 on virtual TUN adapters with a physical limit of 1500.

Guest System (WSL Bash):
ip addr | grep mtu

Output example:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
8: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000

3. Troubleshooting Regulations

Stage 1: Normalization of MTU in WSL

To prevent packet dropping in the VPN tunnel, it is necessary to forcibly limit the MTU of the WSL interface to a secure value that takes into account the overhead of the tunnel protocols.

# Setting a limit of 1400 bytes for the eth3 interface (or the corresponding default)
sudo ip link set dev eth3 mtu 1400

Stage 2: Routing and Metrics Configuration

In WSL 2, there is often a "default gateway race" situation where traffic is randomly distributed between the physical interface (eth0) and the virtual tunnel interface (eth3). To ensure stable operation of agents, it is necessary to explicitly prioritize the tunnel route.

Technical manipulation of the routing table:

1. Removing an undefined route: Tunnels often create a route without an explicit metric, which makes the behavior of the network stack unpredictable.

sudo ip route del default dev eth3

2. Adding a priority route: Setting the metric parameter allows you to set the priority rigidly. The lower the metric value, the higher the priority of the route.

sudo ip route add default dev eth3 metric 10

Note: If the physical gateway has a metric of 25 or higher, setting the value to 10 ensures that Antigravity's gRPC traffic goes through the VPN.

3. Verification of the final table:
The 'ip route` command should show the tunnel interface as the primary (default) with the lowest metric value.

Stage 3: Optimizing the WSL Network mode

In some cases, for transparent interaction with Windows system proxies, it is recommended to switch to interface mirroring mode in the %USERPROFILE%.wslconfig file:

[wsl2]
networkingMode=mirrored
dnsTunneling=true

Important: If an instance initialization error occurs (0x8007054f) indicating a TUN driver conflict, you should switch back to NAT mode.

4. Features of interpretation of the results

Configurations using sing-box proxying (Hiddify) should take into account:

1. ICMP Filtering: The tracepath or mtr commands may return no reply due to ICMP traffic being filtered by the tunnel. This is not a sign of a lack of connectivity for TCP/gRPC Antigravity traffic.
2. DNS Hijacking: It is recommended to check /etc/resolv.conf for the use of the tunnel's internal DNS resolver (for example, 172.19.0.2).

Conclusion

The stability of the Google Antigravity platform directly correlates with the integrity of the data transmission channel. Bringing the network topology to a single MTU and prioritizing routes allows agents to seamlessly synchronize the development context with cloud computing resources.