Multiplexing support (redirect real TCP traffic)

[lars18th]

Hi,

The request is to support this use case:

Phantun client ----------+----> TCP/22 ----+-------> Phantun Server
                         |                 |
SSH Client --------------/                 \---------> SSH server

The objective is to run the Phathun Server listeing in the PUBLIC port 22 (or 443), and pass non-Phantun streams to another server (in this case one real TCP server).

I feel this could be feasible with the use of the --handshake-packet option. So to distinguish between a Phantun client or any other client (tcp) you could use this magic handshake. Then you can process packets to the source of the Phantun client, and resend to the target tcp server all non-Phantun packets received from other sources.

What you think about this enhancement?

[lars18th]

Hi,

No one interested on this? The use case could be simple:

• You want to hide that you are running a wireguard connection through a “fake” TCP port. So you put a simple SSH server or an empty HTTP server on that port. But the port is handle by phantun and it redirects any not-known request connection to that server. Therefore, any port scan over that port will retrieve the generic TCP server.

I feel this is not difficult to achieve. Futhermore it will not consume a lot of resources.
What you think?

[lars18th]

Hi @dndx ,

No comments? This request doesn't have sense? It's out-of-scope? It requires a lot of work?

[lars18th]

Hi @dndx ,

I'm waiting for your response. What I need is simple: run phantun with UDP over FakeTCP obfuscation, but with the option to route real TCP connections to another server.

The objective is to not only obfuscate the connection, but to respond to any TCP client. With the current implementation if you do a test over the used port you don't receive anything. Perhaps if you don't want to implemented the requested type of redirection then you can implement some fake TCP response instead.

The idea is this: if someone that is not a valid client connects to the FakeTCP port on the server (when the handshake_packet fails) then in this case send something that simulates a SSH or HTTPS server (perhaps selectable).

What you think about this idea?