Connection crashes after some time and blocks any attempt at reconnecting

[Clpsplug]

Describe the bug In the Desktop version of Loophole, I have noticed that an hour after creating my tunnel, it crashes with the red box saying "EOF." This box was green before it crashed and the tunnel was working.

I searched this repository for existing reports, and I have found one - #9. There is a topic about the EOF error (relationship to this issue is unknown.) The issue is also linked to #27, which means Loophole already has a reconnect feature. Unfortunately, this red box is staying red without any apparent attempt at reconnecting the tunnel.

Plus, no more manual attempt to recreate a tunnel succeeds after the tunnel crashes because apparently, the crashed tunnel "is already running." This is definitely not the case since the previous one died (further connections to the tunnel times out.) Notice that I have deleted the previously crashed tunnel at this point.

The logs for the specific tunnel contained this line for the reason for the crash:

Listening on remote endpoint for HTTPS failed

I don't know which side (me or LH) you mean by "remote endpoint," the server I was running on localhost for tunneling was running fine. I can connect to the said server from localhost and get the correct response.

To Reproduce Steps to reproduce the behavior (to replicate my setup close enough:)

1. Get any Docker container that exposes an HTTP port to the host running.
2. Check that you can connect to the container via that port.
3. Launch LoopHole Desktop and set up a tunnel that exposes the host port tunneled to the previous Docker container.
   • Do NOT use the custom 502 error page.
   • Use a custom subdomain.
4. Create that tunnel.
5. Observe that the tunnel is working.
6. Wait for about an hour.
7. The tunnel crashes and stays crashed indefinitely.

Expected behavior

• The tunnel should not crash (or is there a limitation in place?)
• In the event it does crash, LH should reconnect the tunnel.

Environment

• OS: macOS Big Sur 11.6.2
• Version: 1.0.0-beta.14 8253b9d

Additional context

The last lines of logs look like the following. Some of the info is redacted because it had some of my information:

2022/2/15 23:44:54  {"type":"MT_RequestTunnelStart_HTTP","payload":{"local":{"host":"127.0.0.1","port":3939,"https":false},"remote":{"disableProxyErrorPage":true,"tunnelId":"5fc75728-17f6-45dc-af94-1d583b6e4ff2","siteId":"<REDACTED>"}}}
2022/2/15 23:44:54  {"type":"MT_LoadingStart","tunnelId":"5fc75728-17f6-45dc-af94-1d583b6e4ff2","message":"Registering your domain..."}
2022/2/15 23:44:59  {"type":"MT_LoadingSuccess","tunnelId":"5fc75728-17f6-45dc-af94-1d583b6e4ff2"}
2022/2/15 23:44:59  {"type":"MT_TunnelStart","tunnelId":"5fc75728-17f6-45dc-af94-1d583b6e4ff2"}
2022/2/15 23:44:59  {"type":"MT_LoadingStart","tunnelId":"5fc75728-17f6-45dc-af94-1d583b6e4ff2","message":"Starting local TLS proxy server"}
2022/2/15 23:44:59  {"type":"MT_LoadingStart","tunnelId":"5fc75728-17f6-45dc-af94-1d583b6e4ff2","message":"Starting local proxy server... "}
2022/2/15 23:44:59  {"type":"MT_LoadingSuccess","tunnelId":"5fc75728-17f6-45dc-af94-1d583b6e4ff2"}
2022/2/15 23:44:59  {"type":"MT_LoadingStart","tunnelId":"5fc75728-17f6-45dc-af94-1d583b6e4ff2","message":"Initializing secure tunnel... "}
2022/2/15 23:45:01  {"type":"MT_LoadingSuccess","tunnelId":"5fc75728-17f6-45dc-af94-1d583b6e4ff2"}
2022/2/16 0:45:01   {"type":"MT_LoadingFailure","tunnelId":"5fc75728-17f6-45dc-af94-1d583b6e4ff2","error":"EOF"}
2022/2/16 0:45:01   {"type":"MT_TunnelLog","message":"Listening on remote endpoint for HTTPS failed","class":"danger","tunnelId":"5fc75728-17f6-45dc-af94-1d583b6e4ff2"}
2022/2/16 0:45:01   {"type":"MT_TunnelStartFailure","tunnelId":"5fc75728-17f6-45dc-af94-1d583b6e4ff2","error":"EOF"}

[Morishiri]

Hello @Clpsplug, thanks for the detailed report. I've received such report over mail as well and I already started investigation. We have a small bug in our SSH gateway which I'm working on a fix to.

In the meantime, I've applied a workaround and you should be able to recreate the tunnel (it should no longer say that the tunnel is already running). Please let me know if that's working.

As I mentioned above I will continue working on it and will update this issue once the problem is gone.

[Clpsplug]

@Morishiri, thank you for your reply. I am currently testing the behavior out. So far, the tunnel has not appeared to crash yet after about three hours, but I do see that the tunnel has died internally several times. The reconnection attempts seem to be working now. Interestingly, the crashes still occur precisely in a one-hour interval.

Should I keep this open until the underlying tunnel crashes are resolved, or close it because the reconnect is now working? Nvm, I'll keep this one open.

As I mentioned above I will continue working on it and will update this issue once the problem is gone.

[Morishiri]

The re-connection happens because of our reverse proxy timeout which I will increase to 24h, but the reason for not being able to connect again is more problematic.

[Morishiri]

@Clpsplug the increased timeout is now deployed, let us know if you encounter any disconnect from now one (except the one every 24h).

[MaxwellJK]

Hi @Morishiri i set up a tunnel the other day, around lunchtime, and from the log I could see the tunnel connection dropping every hour and successfully reconnecting till late evening (11pm or similar) when the connection dropped and it didn't reconnect anymore. I am using loophole cli version 1.0.0-beta.15_linux_64bit running on my Synology NAS.