HI, I setup systemd services for both client and server but it looks like the client doesn’t recconect autoamtically when the external IP changes and just hangs until it’s restarted manually.
Is this expected?
Is there any way around this?
Thanks!
You mean when the public IP of the server changes, right?
This is likely relate to this long-standing issue: https://github.com/boringproxy/boringproxy/issues/41.
You might be able to find some workarounds in that thread.
The good news is that this is still an important issue that I plan on fixing in the near future. I still have a few other things that need to come first though.
Unfortunately I mean the client, the server is on a VPS with a static IP.
The client is on an ADSL connection and it changes IP every cca 24 hours. Every time that happens the tunnel drops until the client service is restarted.
Edit:
I also got these messages and everything failed until it was manually restarted
ssh: tcpip-forward request denied by peer
(not sure if it’s connected in any way)
Gotcha. You might find this guide useful for setting up the client: https://github.com/boringproxy/boringproxy/issues/108. It’s focused on windows, but the general principles are similar. Basically you can set up some sort of a script to run regularly and restart the client if it stops working. This is currently probably your best option.
1 Like
Hi,
By my side the problem is even trickier, cause it stops working but boringproxy daemon (I created one for the purpose of auto restarting) is still running.
So in the end tunnels just ended to be carried out but both server and client are working perfectly. The only error that I have is a single : Apr 08 01:45:04 hostname boringproxy[3795342]: 2022/04/08 01:45:04 http: TLS handshake error from 127.0.0.1:51072: EOF
You can see the visual http probe log here:
To fix it I can simply manually re-bore every tunnel from server GUI interface or restart boringproxy client.
Not sure I’m understanding all this correctly. Did you end up getting a setup that’s working well enough for you?
Sorry, poorly worded → noop but I don’t have enough information to provide here to debug it further, unless you guess some root cause…
I just found this thread and I’ve been experiencing the same thing. I just made the connection that the trigger for my tunnels collapsing was the dynamic ip change.
One additional quirk that I’m seeing is that I can’t just do a systemctl restart on the client. I have to stop it, wait for a couple of minutes and then start it. I don’t know but I suspect there’s some sort of caching going on. I used to think I had to recreate all the tunnels but now I know that if I just wait a little while after the client service is stopped before starting it again then all the tunnels re-establish fine.