Host Wireguard Tunnel

[airmon-ster]

If port forwarding doesnt work and there are still issues with hole-punching, the final option for some will be to use a cheap wireguard tunnel to cloud instance to tunnel in traffic to the host. It kind of goes against some of the principles of the project, but if it works, it works.... puts the players back in control of how they want to host their server.

Easiest way is to do this: https://gist.github.com/Quick104/d6529ce0cf2e6f2e5b94c421a388318b

[airmon-ster]

windows does not have a native router to route from a windows client to the ps2 (portproxy only works with tcp). The windows native router is only available on windows server, so that wont work either. Hosts using this method will have to have it routed through a linux box with iptables forwarding it to the ps2

[SPEARTECH]

since we talked about this in discord, writing here... wireguard host and client setup seems simple, but not sure how traffic could be directed to a physical console... perhaps connecting the console ethernet to pc in a bridged connection would solve the problem? maybe it works for emulator just fine?

[SPEARTECH]

i was looking for (free) options that take care of NAT traversal based on wireguard... i see zerotier is one of them, may give that a shot with the ps2 ethernet connected to pc via ethernet -> usb adapter.

[SPEARTECH]

Wireguard notes_6-29-24.docx Made ubuntu vm in azure with public ip Installed wireguard on vm

Wireguard server local ip = 10.0.1.1 Wireguard client1 local ip = 10.0.1.2 Wireguard client2 local ip = 10.0.1.3 Successfully able to ping client1 <-> client2

Attempted scops gui app client connection to external ip – no games found Attempted emulator to emulator and console to console via ps2 ethernet -> shared wireguard adapter

Ps2 net configs consisted of:

• Auto
• Static
  • 192.168.1.253
  • 255.255.255.0
  • 192.168.1.1

Verified udp comms from wireguard client to client via:

• client1$ ncat -u -l 3658
• client2$ echo "testing" | nc -u 10.0.1.2 3658
• Communication successful with error message of:
  • "A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself."
• wireguard configs set MTU = 1420 to ensure buffer size with same result
• perhaps testing with iperf would give more insight:
  • wireguard client$ iperf -s -u -i 1
  • external machine$ iperf -c -u -b 1M -t 10