Connector and head-less client on same host. windows/ios clients lose connectivity to host

Support / Troubleshooting
1

Hi everyone, :smile:

Loving twingate so far. Have an issue that is puzzling me and would love guidance/advice on finding a potential solution.

I have the twingate connector and client installed on a VPS running Almalinux 9.3 (called it, rproxy)

This VPS (rproxy) serves as a reverse proxy for my backend server (call it, bend01)

The connector serves as an entry way for my clients (e.g. windows laptop, iPhone) to reach the VPS (rproxy) from the outside securely without opening inbound 22 and 9090 to the world.

Port 22 and Port 9090 map to services that enable me to manage the rproxy server. My iPhone and Windows laptop have the twingate clients installed, so they can reach rproxy on those ports.

The headless client on the VPS (rproxy) connects to my backend server (bend01), and the backend server (bend01) has the twingate connector on it.

When both the client and connector are installed on VPS (rproxy), my windows and iPhone clients stop communicating to the VPS (rproxy).

When the connector and only the connector is installed on VPS (rproxy), my windows and iPhone clients can reach it no problem, but, when the head-less client is installed my windows and iPhone clients cannot reach it anymore.

Here is what i’m trying to accomplish:

I have services and apps running on my backend server, some services (e.g. Jellyfin) I want to access without needing a connector installed on every device.

I have the connector set-up on my backend server, this is what the headless client on my reverse proxy instance connects to in order to reach the backend server and it’s services and apps, securely.

With this set-up I can open port 443 on the reverse proxy, and the proxy will take incoming requests and route to the appropriate backend services. This design masks my backend from the world, and the world only sees my reverse proxy and not my backend server.

All that said, I want to know why, when the connector and client is installed at the same time on my rproxy host, my clients, iphone and windows, cannot communicate to it.

Thank you so much! :grin:

2

I’m not actually entirely sure why having both installed on the machine would prohibit you from connecting, other than some kind of resource conflict occurring.

That being said, to clarify, is rproxy on the same network as bend01?

Or, is the ONLY purpose of rproxy to connect to bend01?

If you have the connector installed on bend01, rproxy becomes redundant if you’re using Twingate.

You would be able to access anything reachable over the network from bend01/[wherever the connector is installed] via Twingate, and wouldn’t need to get up to any sort of proxy/jumpbox shenaniganss, and would still maintain the isolation of your resources from the open world.

You do not need a connector installed on every device.

Let me know if I’ve misunderstood the setup or if you’d like more clarification.

Thanks,

3

Hi Arthur and thank you for the response! :slight_smile:

is rproxyon the same network asbend01 ?

rproxy, is not on the same network as bend01.

both are in separate datacenters on separate providers.

is the ONLY purpose of rproxy to connect to bend01 ?

rproxy’s purpose is to connect to bend01. rproxy will have port 443 open for incoming traffic, rproxy will act as a LB w/ SSL termination for services running on bend01.

Originally used wireguard for this purpose but it became cumbersome to maintain overtime, which lead me to twingate as an alternative :slight_smile:

I have this design in mind for services that I need accessible to the world.

4

So my working theory is the following:

  1. You have the public Internet IP for rproxy defined as a resource within Twingate
  2. When the connector is installed on bend01, and you attempt to reach rproxy, the traffic transits from the WAN IP of bend01 to rproxy and things work normally.
  3. When you install the connector on rproxy, and you attempt to reach rproxy, the traffic is essentially trying to leave via rproxy and then immediately hairpin back to it, and something is preventing that. Likely firewall rules or network configurations at the host level.

What you could potentially do is add some sort of faux host entry on rproxy that is an alias for 127.0.0.1, and add that as a Twingate resource (something like rproxy.int) and then that way when you’re accessing the rproxy configuration stuff, you would go to https://rproxy.int:8888/ or whatever, and Twingate would route that through the connector and that machine would treat it as an internal DNS lookup rather than a specific external transit path.

Clear as mud?