Tunnel for TCP service

I set up a tunnel that will forward to a TCP service (non-http), however when I test it, CloudFlare seems to be forcing me to speak HTTP, otherwise I get bad request. Problem is the service I’m exposing is not an HTTP service. So a few questions:

  1. Is it true that if someone access the URL directly, cloudflare expects the request to be http (even if upstream is arbitrary tcp)?
  2. Is it true that if I want tcp forwarding as-is, I have to install the warp agent (as in the SSH tutorial) and let it proxy the traffic?
  3. Otherwise I’m left with cloudflare Spectrum (which requires enterprise subscription to forward my protocol)?

The reason I cannot install warp agent (on client machines) is this protocol is for out-of-band management (Intel AMT), where OS might not be present at all. And I could not afford cloudflare enterprise because I’m just a personal user trying to fix computers for my family…

Basically, all of these questions are true.

You need at least one agent in the network that can access the machines you want to connect to and you need the agent on your computer to connect to them.

Alternatively you can use this, but it’s slightly different and still requires an agent in the remote network.


1 Like

Thanks for the fast reply! Installing agent on server is no issue (which I’m already doing); however the client machines cannot have agents.

As in the targets or your computer?

My computer.

Then something is required, be it the cloudflared agent or the Warp client. You need to tunnel the TCP somewhere. Doing TCP tunnelling free for all is Spectrum-only.

So more context: if you use some Intel or AMD cpu there is software running at very low level (below operating system) for remote management. It can be configured to connect to some remote address but obviously running an agent is not possible in that environment.
There is workaround of course like running the agent on some rpi and expose it as a proxy (which the remote control software supports), however that complicates things a lot. I might need to look for other route or just expose the port to Internet (less ideal though)

I get that, I know what those types software are, they exist for servers as well and they are even more low level.

I feel you are not understanding where I am talking about.

You can proxy TCP to machine A if you are able to reach it via the local network from the location of the agent. You can do whole network/IP or direct to machine (with a subdomain per machine).

  1. The first is via Warp and Cloudflare for Teams (the link above), it requires the cloudflared agent in a machine in that network + the Warp client on the computer or device from which you need to access it.
  2. The second requires cloudflared on a machine (same as above, but requires a rule per target in the config.yml file) + cloudflared on the computer from which you need to access the targets. You can maybe create a server which can share this “connection” to the local network, but it’s limited to one target and port combination per connection.

Ok I think there is some ambiguous wording in my previous posts.

  • Node 1 is the machine to be managed remotely. Node 1 does not have OS.
  • Node 2 is the machine I will use to manage node 1. Node 2 has agent installed.

Node 1 will initiate a connection to node 2.

You have answered my question wrt difference between argo tcp tunnel and spectrum. However from your last post it seems I caused the impression that node 2 need to connect to node 1, which is not the case.

That is not possible. To initiate a connection you need a client installed somewhere, so it requires an OS. You need to continuously have the connection set-up as all connections can’t start from node 1, as it doesn’t see your computer. In any case.

To have the “target” connect to you computer it needs to see it, so the actual target would be your computer, making it impossible. It would barely work with Spectrum.

You need a site-to-site VPN there to have full 2-way connectivity.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.