github-starred/newt
2
0
Fork 0
mirror of https://github.com/fosrl/newt.git synced 2026-03-09 07:12:28 -05:00
Code Issues 21 Packages Projects Releases 25 Wiki Activity

Newt client fails to establish connection to WireGuard server - persistent ICMP timeouts #36

New Issue
Closed
opened 2025-11-19 07:12:33 -06:00 by GiteaMirror · 1 comment
GiteaMirror commented 2025-11-19 07:12:33 -06:00
Owner
Copy Link

Originally created by @emon5122 on GitHub (Jun 14, 2025).

Newt client fails to establish connection to WireGuard server - persistent ICMP timeouts

Description

The Newt client (v1.2.1) is unable to establish a stable connection to the Pangolin WireGuard server. After successful registration, all ping attempts to the server IP fail with ICMP timeout errors, despite the WireGuard device being created successfully.

Environment

  • Newt Version: 1.2.1
  • Server Endpoint: pangolin.example.com:51820
  • Server IP: 100.89.128.1
  • Tunnel IP: 100.89.128.4
  • Date/Time: 2025-06-14 19:33:48 - 19:37:19

Steps to Reproduce

  1. Start Newt client
  2. Client sends registration message
  3. Client receives connection configuration from server
  4. WireGuard device is created successfully
  5. Client attempts to ping server IP (100.89.128.1)

Expected Behavior

  • Ping attempts to the WireGuard server should succeed
  • Stable connection should be established
  • No timeout errors should occur

Actual Behavior

  • All ping attempts (1-16) fail with "failed to read ICMP packet: i/o timeout"
  • Connection to server is lost immediately after WireGuard device creation
  • Client enters continuous reconnection mode
  • Ping retry delays increase progressively (3s → 4.5s → 6.75s)

Additional Context

  • Docker socket checks are working correctly (available=true)
  • Docker container operations are functioning (9 containers listed)
  • TCP proxy was successfully started during the session (100.89.128.4:63703 to app:80)
  • The issue appears to be specifically with ICMP connectivity to the WireGuard server

Log Excerpt

2025-06-15 01:33:49 INFO: WireGuard device created. Lets ping the server now...
2025-06-15 01:33:59 WARN: Ping attempt 1 failed: failed to read ICMP packet: i/o timeout
2025-06-15 01:34:39 WARN: Connection to server lost. Continuous reconnection attempts will be made.
2025-06-15 01:34:39 WARN: Please check your internet connection and ensure the Pangolin server is online.
Originally created by @emon5122 on GitHub (Jun 14, 2025). # Newt client fails to establish connection to WireGuard server - persistent ICMP timeouts ## Description The Newt client (v1.2.1) is unable to establish a stable connection to the Pangolin WireGuard server. After successful registration, all ping attempts to the server IP fail with ICMP timeout errors, despite the WireGuard device being created successfully. ## Environment - **Newt Version**: 1.2.1 - **Server Endpoint**: pangolin.example.com:51820 - **Server IP**: 100.89.128.1 - **Tunnel IP**: 100.89.128.4 - **Date/Time**: 2025-06-14 19:33:48 - 19:37:19 ## Steps to Reproduce 1. Start Newt client 2. Client sends registration message 3. Client receives connection configuration from server 4. WireGuard device is created successfully 5. Client attempts to ping server IP (100.89.128.1) ## Expected Behavior - Ping attempts to the WireGuard server should succeed - Stable connection should be established - No timeout errors should occur ## Actual Behavior - All ping attempts (1-16) fail with "failed to read ICMP packet: i/o timeout" - Connection to server is lost immediately after WireGuard device creation - Client enters continuous reconnection mode - Ping retry delays increase progressively (3s → 4.5s → 6.75s) ## Additional Context - Docker socket checks are working correctly (available=true) - Docker container operations are functioning (9 containers listed) - TCP proxy was successfully started during the session (100.89.128.4:63703 to app:80) - The issue appears to be specifically with ICMP connectivity to the WireGuard server ## Log Excerpt ``` 2025-06-15 01:33:49 INFO: WireGuard device created. Lets ping the server now... 2025-06-15 01:33:59 WARN: Ping attempt 1 failed: failed to read ICMP packet: i/o timeout 2025-06-15 01:34:39 WARN: Connection to server lost. Continuous reconnection attempts will be made. 2025-06-15 01:34:39 WARN: Please check your internet connection and ensure the Pangolin server is online. ```
GiteaMirror commented 2025-11-19 07:12:34 -06:00
Author
Owner
Copy Link

@emon5122 commented on GitHub (Jun 15, 2025):

Issue Resolved - Cloudflare Proxy Configuration Missing

Root Cause Identified: Missing Cloudflare proxy configuration in config.yml

I discovered that I had overlooked a critical configuration requirement when using Cloudflare proxy (orange cloud) with Pangolin. The issue was not related to client-side networking or firewall problems, but rather a server-side configuration issue.

The Problem

When Cloudflare proxy is enabled, it obscures the destination IP of the host, which prevents WireGuard from connecting properly to the VPS. The Newt client was receiving the correct registration and configuration, but couldn't establish the actual WireGuard connection because it was trying to connect through Cloudflare's proxy network instead of directly to the VPS.

The Solution

Added the explicit VPS IP address configuration to config.yml:

gerbil:
  start_port: 51820
  base_endpoint: "YOUR_ACTUAL_VPS_IP_HERE"  # Replace with actual VPS IP

Additional Requirements for Cloudflare Proxy

For anyone else encountering this issue while using Cloudflare proxy:

  1. SSL/TLS Mode: Must be set to "Full (Strict)" - will NOT work with "Full" or "Automatic"
  2. Wildcard Certificates: Ideally setup wildcard certificates with Traefik using DNS challenge
  3. VPS IP Configuration: Must explicitly set the actual VPS IP address in the gerbil configuration

References

Closing this issue as resolved. Thanks to anyone who may have been investigating this!

@emon5122 commented on GitHub (Jun 15, 2025): ## Issue Resolved - Cloudflare Proxy Configuration Missing **Root Cause Identified**: Missing Cloudflare proxy configuration in `config.yml` I discovered that I had overlooked a critical configuration requirement when using Cloudflare proxy (orange cloud) with Pangolin. The issue was not related to client-side networking or firewall problems, but rather a server-side configuration issue. ### The Problem When Cloudflare proxy is enabled, it obscures the destination IP of the host, which prevents WireGuard from connecting properly to the VPS. The Newt client was receiving the correct registration and configuration, but couldn't establish the actual WireGuard connection because it was trying to connect through Cloudflare's proxy network instead of directly to the VPS. ### The Solution Added the explicit VPS IP address configuration to `config.yml`: ```yaml gerbil: start_port: 51820 base_endpoint: "YOUR_ACTUAL_VPS_IP_HERE" # Replace with actual VPS IP ``` ### Additional Requirements for Cloudflare Proxy For anyone else encountering this issue while using Cloudflare proxy: 1. **SSL/TLS Mode**: Must be set to "Full (Strict)" - will NOT work with "Full" or "Automatic" 2. **Wildcard Certificates**: Ideally setup wildcard certificates with Traefik using DNS challenge 3. **VPS IP Configuration**: Must explicitly set the actual VPS IP address in the gerbil configuration ### References - [[Pangolin Cloudflare Proxy Documentation](https://docs.fossorial.io/Pangolin/Configuration/cloudflare-proxy)](https://docs.fossorial.io/Pangolin/Configuration/cloudflare-proxy) - [[Wildcard Certificates Setup](https://docs.fossorial.io/Pangolin/Configuration/wildcard-certs)](https://docs.fossorial.io/Pangolin/Configuration/wildcard-certs) - [[Cloudflare SSL/TLS Encryption Modes](https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/)](https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/) Closing this issue as resolved. Thanks to anyone who may have been investigating this!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
good first issue
help wanted
Improvement
pull-request
Mirrored from GitHub Pull Request
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/newt#36
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?