mirror of
https://github.com/fosrl/pangolin.git
synced 2026-05-30 10:36:12 -05:00
[GH-ISSUE #2186] The web UI shows the site as online, but actual access results in a Gateway Timeout error. #2091
Reference in New Issue
Block a user
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?
Originally created by @Transwarpcom on GitHub (Dec 30, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2186
Describe the Bug
The web UI shows the site as online, but actual access results in a Gateway Timeout error. The firewall is correctly configured, Cloudflare DNS proxy is disabled, and the site was installed using the official installer.
The log is as follows
Dec 30 23:13:29 Ubuntu-LXC systemd[1]: Started newt.service - Newt.
Dec 30 23:13:29 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:13:29 Newt version 1.8.1
Dec 30 23:13:30 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:13:30 Server version: 1.14.1
Dec 30 23:13:30 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:13:30 Websocket connected
Dec 30 23:13:30 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:13:30 Connecting to endpoint: pangolin.mydomain.com
Dec 30 23:14:01 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:01 Initial reliable ping failed, but continuing: all 5 ping attempts failed, last error: failed to read ICMP packet: i/o timeout
Dec 30 23:14:06 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:06 Ping attempt 1 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:14:06 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:14:06 Started tcp proxy to 192.168.1.1:80
Dec 30 23:14:06 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:14:06 Started tcp proxy to localhost:5443
Dec 30 23:14:11 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:11 Ping attempt 2 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:14:18 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:18 Ping attempt 3 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:14:25 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:25 Ping attempt 4 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:14:32 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:32 Ping attempt 5 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:14:32 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:14:32 Increasing ping retry delay to 3s
Dec 30 23:14:40 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:40 Ping attempt 6 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:14:48 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:48 Ping attempt 7 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:14:50 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:50 Periodic ping failed (2 consecutive failures): all 2 ping attempts failed, last error: failed to read ICMP packet: i/o timeout
Dec 30 23:14:56 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:14:56 Ping attempt 8 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:15:04 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:04 Ping attempt 9 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:15:12 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:12 Ping attempt 10 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:15:12 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:15:12 Increasing ping retry delay to 4.5s
Dec 30 23:15:21 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:21 Periodic ping failed (3 consecutive failures): all 2 ping attempts failed, last error: failed to read ICMP packet: i/o timeout
Dec 30 23:15:21 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:21 Ping attempt 11 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:15:31 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:31 Ping attempt 12 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:15:40 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:40 Ping attempt 13 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:15:50 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:50 Ping attempt 14 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:15:51 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:51 Periodic ping failed (4 consecutive failures): all 2 ping attempts failed, last error: failed to read ICMP packet: i/o timeout
Dec 30 23:15:51 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:15:51 Connection to server lost after 4 failures. Continuous reconnection attempts will be made.
Dec 30 23:15:52 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:15:52 Stopping ping check
Dec 30 23:15:52 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:15:52 Connecting to endpoint: pangolin.mydomain.com
Dec 30 23:16:22 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:16:22 Initial reliable ping failed, but continuing: all 5 ping attempts failed, last error: failed to read ICMP packet: i/o timeout
Dec 30 23:16:27 Ubuntu-LXC newt[21626]: WARN: 2025/12/30 23:16:27 Ping attempt 1 failed: failed to read ICMP packet: i/o timeout
Dec 30 23:16:27 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:16:27 Started tcp proxy to 192.168.1.1:80
Dec 30 23:16:27 Ubuntu-LXC newt[21626]: INFO: 2025/12/30 23:16:27 Started tcp proxy to localhost:5443
Environment
To Reproduce
I encountered this problem after a normal installation. I've tried clean installation multiple times.
Expected Behavior
Working correctly
@Transwarpcom commented on GitHub (Dec 30, 2025):
Incidentally, my tests on non-LXC physical machines were the same.
@AstralDestiny commented on GitHub (Dec 30, 2025):
Where's newt in relation to pangolin? If newt is on the same network it'll fail as hairpin nat, You can force a connection by rewritiing it to attempt a connection to the lan ip over the wan ip.. The ICMP time out is saying the tunnel isn't even online, That happens over the tunnel and not a connection between directly outside of the tunnel.
@Transwarpcom commented on GitHub (Dec 31, 2025):
I'm certain that Pangolin and Newt are not on the same network.
@Transwarpcom commented on GitHub (Dec 31, 2025):
May same to: https://github.com/fosrl/pangolin/issues/576
@Transwarpcom commented on GitHub (Dec 31, 2025):
I have identified the root cause. This is not a bug in the software, but a network censorship issue (GFW in Mainland China) blocking the default WireGuard UDP port.
Analysis:
Control Plane (TCP/WebSocket): The web UI shows the client as "Online" because the control channel uses WebSocket (likely over TCP 443/80), which is not blocked.
Data Plane (UDP/WireGuard): The actual traffic tunnel relies on WireGuard, which defaults to UDP 51820. My packet capture confirms that the WireGuard handshake is being dropped by the firewall.
Evidence (tcpdump): I captured the traffic on the client side. The logs show repeated Handshake Initiation packets (length 148) being sent to the server's port 51820, but zero response packets are received. The connection is completely blocked at the network level.
Plaintext
Client sending Handshake Initiation (Length 148) every 5 seconds
18:09:00.858 IP 192.168.x.x.21456 > [Server_IP].51820: UDP, length 148
18:09:05.859 IP 192.168.x.x.21456 > [Server_IP].51820: UDP, length 148
18:09:10.860 IP 192.168.x.x.21456 > [Server_IP].51820: UDP, length 148
Result: Only OUT packets, no IN packets.
Conclusion: The "Gateway Timeout" occurs because the UDP tunnel never successfully establishes, despite the WebSocket being connected. The "ICMP ping timeout" in the logs is a symptom of the broken tunnel.
Recommendations:
User-side Workaround (Proxy): Since changing ports is often insufficient against protocol detection, it is recommended to run the newt client behind a proxy or VPN software (e.g., using a transparent proxy or a router-level tunnel) to encapsulate the UDP traffic and bypass the block.
Feature Request (Obfuscation / TCP Fallback): In high-censorship regions (like China), raw WireGuard protocol is easily identified and blocked. I strongly suggest the project consider adding a TCP fallback mode or UDP obfuscation (similar to udp2raw) functionality. This would allow the tunnel to survive in restrictive network environments where UDP is throttled or blocked.
@sagehou commented on GitHub (Jan 30, 2026):
Same issue, this feature request (Obfuscation / TCP Fallback) seems to be the key.