sorz/sstp-server

Inter-peer port communication

Closed this issue · 4 comments

Sidefix commented

Hello!

I have been successful in establishing connections between two peers using this VPN. Performing Test-NetConnection on the other peer will result in a successful ping, and I am also able to run netcat to do UDP test on another port as well, using PsPing on the other client to test. Everything works well.

What does not work at all however is games. Anything I have tried to run that should work over LAN simply fails to 'discover'. Worse yet, the ports seem to be somehow blocked. For example, Starcraft over LAN uses UDP 6112. I am able to perform a successful netcat/psping test on 6112, but the same machines are unable to see each other in Starcraft. Additionally, running and hosting a game in Starcraft on machine 1 and doing the same port 6112 psping test from machine 2 will fail.

The most I could narrow down this issue is at the adapter level; specifically, no matter what I have attempted to do (including using ForceBindIP with both the IP and interface ID), I have not been able to get the application to use the correct adapter. DemonStar, a very old game, has a 'Get IP Address' function that outputs the currently used IP address. Using other VPN solutions, it will pick up the relevant adapter interface correctly and use that IP address. With this however, I have been completely unable to get it to use the correct interface.

To summarize, although port connections and most functions work correctly, I have not been able to get games to use the correct network interface, and I have not been able to find a solution online. Has anyone else encountered / attempted this, and if so is this a known issue with sstp VPN types or am I missing something?

Thank you in advance!

Sidefix commented

After doing quite a bit of digging and spending much more time on this than it deserves, I have partially identified the issue.

The Get-NetIPInterface command picks up the VPN adapter in Windows, but the Get-NetAdapter command does not

I believe that applications, while not using Powershell, have this same issue. Specifically, they will never see the VPN adapter despite it being active and working as intended. Clearly an application/client issue in how adapters are picked up, and not a server issue.

I will still keep this issue open, maybe someone has something to add? Otherwise feel free to close.

tisj commented

@Sidefix Normally applications find each other by means of IP addresses and/or port numbers. Depending on the configuration of the sstp-server, the client receives a (new) IP address from a configured range. For convenience this could be an IP address that is part of the IP subnet configured on the LAN of the server and in which the game server/peer resides using a different IP in the same LAN.

When you start a game one would expect it does not bind to a specifc IP address on the host, but rather keeps an open mind and allows to connect towards any application/server elsewhere on any device. Then all depends on IP routing and/or ethernet ARP resolution.

It may be useful for you to install a network debugging tool like wireshark that allows to capture/visualize network packets on any interface. When you launch the game, you should see some network requests appear and the tool allows to see where they are going and whether or not a request is being answered.

Maybe you are in need of extra routings over the VPN tunnel (once it is established) or you could benefit from proxy ARP.

Sidefix commented

Hello @tisj !

Unfortunately I have been troubleshooting this for a while with no success.
As I stated initially, I can ping one peer to the other, but further testing revealed that not even folder sharing in Windows will work between peers in the VPN. I've been trying feverishly to get it to work with various iptables configs, with no success so far:

sudo sysctl -w net.ipv4.ip_forward=1
sudo sysctl -w net.ipv4.ip_dynaddr=1
sudo sysctl --system
sudo iptables -A POSTROUTING -t nat -o ppp+ -j MASQUERADE
sudo iptables -I POSTROUTING -t nat -o ppp+ -j MASQUERADE
sudo iptables -I FORWARD -i ppp+ -o ppp+ -j ACCEPT
sudo iptables -A FORWARD -i ppp+ -o ppp+ -j ACCEPT
sudo iptables -A FORWARD -i ppp+ -j ACCEPT
sudo iptables -A FORWARD -o ppp+ -j ACCEPT
sudo iptables -I FORWARD 1 -i ppp+ -o ppp+ -m state --state RELATED,ESTABLISHED -j ACCEPT	
sudo iptables -F FORWARD
sudo iptables -A FORWARD -j ACCEPT
sudo iptables -A POSTROUTING -t nat -o ppp+ -j MASQUERADE
sudo iptables -A POSTROUTING -t nat -o eno1 -j MASQUERADE
sudo iptables -A INPUT -i ppp+ -j ACCEPT
sudo iptables -A OUTPUT -o ppp+ -j ACCEPT
sudo iptables -A FORWARD -i ppp+ -o eno1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i eno1 -o ppp+ -m state --state RELATED,ESTABLISHED -j ACCEPT

To be clear, I haven't used all of these at the same time. Rather, I've used all of these in different combinations at different times with no success.

Sidefix commented

Hello!

Just in the interest of posting an update and closing this issue, I've managed to make significant progress.

Indeed, when correctly configured, everything works as intended. The issue is strictly on the server (Linux, not sstp) side configuration, which can be mitigated through iptables.

The simplest rule setup to achieve my desired goal is:

sysctl -w net.ipv4.ip_forward=1

sysctl -w net.ipv4.ip_dynaddr=1

iptables -A POSTROUTING -t nat -o eno1 -j MASQUERADE

iptables -A INPUT -i ppp+ -j ACCEPT

iptables -A FORWARD -i ppp+ -j ACCEPT

iptables -A PREROUTING -t nat -i ppp+ -p udp -s 10.0.10.3 -j DNAT --to 10.0.10.2

iptables -A PREROUTING -t nat -i ppp+ -p udp -s 10.0.10.2 -j DNAT --to 10.0.10.3

Those last 2 rules are the clincher. The reason the clients were (sometimes) unable to communicate was because the packets used in LAN discovery for games are broadcast to 255.255.255.255; the mitigation is the rules I've set there, but they're hardcoded and have to be applied to each individual client address. I'm currently researching how / if this can be achieved dynamically as with the other rules.

Thank you again @tisj for all the help!

Closing.