Ability for client to specify destination to server

[jamesmcm]

Instead of configuring the server with a fixed destination address with -r, it would be really useful if the client could tell the server which destination it wants, and the server would store this on a per client basis (e.g. by source IP - like NAT).

So instead of having the current situation:

# Client
sudo udp2raw -c -a -l $DUMMY_WIREGUARD_PEER -r $REMOTE:$RPORT -k $KEY --raw-mode faketcp &
# Server
sudo udp2raw -s -l0.0.0.0:$OPEN_LISTEN_PORT -r $REAL_WIREGUARD_PEER -k $KEY --raw-mode faketcp -a

Where all connections are routed to the same -r destination on the udp2raw server, one could do:

# Client
sudo udp2raw -c -a -l $DUMMY_WIREGUARD_PEER -r $REMOTE:$RPORT -k $KEY --raw-mode faketcp --destination $REAL_WIREGUARD_PEER &
# Server
sudo udp2raw -s -l0.0.0.0:$OPEN_LISTEN_PORT -k $KEY --raw-mode faketcp -a

Where the server -r is now specified as --destination on the client.

So multiple clients could tunnel via the same udp2raw server simultaneously, but to different actual Wireguard endpoints.

The udp2raw client would need to send this desired destination address to the server when it first establishes the connection.

[basncy]

If you want to increase the VPN speed via the Internet, try this program starting with a bridge topology.

If you want to create a (faketcp tunnel) gateway described in this issue, you can create DNAT with iptables per client source IP to per udpdeminer instance on a common gateway server. This is also firewall policy friendly for some company networks.

If you really need a TCP rather than UDP connection, you can do DNAT for each wg client per udp2raw client per instance as a temporary solution. While the advantages of udpdeminer are:

1. NO deployment on server side, especially those maintained by third party,
2. No heartbeat traffic waste.
3. NO MTU issue.

Furthermore, if you are strong on programming, you can have one udpdeminer instance to achieve your goals with hookpath.cmd.sh Tutorial, sample, The steps are:

1. wireguard client initial a udp connection.
2. udpdeminer trigger hookpath.cmd.sh with EVENT=startpre, in the script, you search conntrack -p udp -L| grep $STREAMID, then you get which client does this UDP connection is associated with.
3. Option 1): Then, insert OUTPUT DNAT with --comment "DNAT for $STREAMID" iptables rules.
   Option 2): For udpdeminer version >=1.3.0 you can parse --hookip customize, and in your hook script, return the physical server IP:Poprt, telling udpdeminer redirect traffic to this wireguard server instead) sample
4. hookpath.cmd.sh with EVENT=stoppost, if goes step 3 option1, delete the previouse DNAT iptables rule--comment "DNAT for $STEAMID"

The ONLY thing to differentiate client is by STREAMID for udpdeminer hook script, which eaquals to source port, so you have to preconfig the client to bind to different port for wireguard, in case you get multiple result from conntrack.

[basncy]

This is a case to dynamic changing server IP:Port on running time, but you can take a look.

[jamesmcm]

It'd be nice if it were possible by default on the server and client though, like the target_addr in forwarding mode in Trojan - https://trojan-gfw.github.io/trojan/config.html

In the end I just used Trojan instead for this, as it's much easier

[basncy]

So you need a tool that inspects your traffic.
Unfortunatiy, both udp2raw and udpdeminder are design to forward traffic AS IS.