1

I've recently set up a VPN for playing LAN games with some friends. I have a Linux server running pptpd and have successfully been able to connect on Windows using the VPN client built into the operating system. I have tested that the VPN correctly routes information between clients (including broadcast messages). It creates a virtual network adapter on each client that is given highest priority on the system. This means all network connections use it by default (e.g. a Web browser) and it is returned first when doing name queries (e.g. results returned from socket APIs like getaddrinfo() and gethostbyname()). The issue I am having is that the particular game we want to play is not binding its UDP sockets to the correct network interface. The game process instead explicitly binds to the interface of the original network connection (the Windows equivalent of eth0 or wlan0). I want it to bind to the VPN adapter (the Windows equivalent of ppp0).

This particular game is called Battle For Middle-Earth by EA Games. When inside the LAN multiplayer lobby, the game binds a socket to UDP port 8086. It uses this port to send broadcast datagrams to alert other peers it is available AND to receive alerts from other peers. If 8086 is unavailable, it binds to the next sequential port. For this reason it sends copies of the same broadcast message to a range of ports (i.e. 8086..8095). Once a game has been started, the peers start sending directed datagrams to each other as opposed to broadcasts. As it stands right now, none of the game traffic is hitting the VPN. Here is some netstat output that shows the game bound to the 10.0.1.0/24 network (allocated by a home router) as opposed to the 192.168.0.0/24 network (allocated by the VPN server):

UDP    10.0.1.18:137          *:*
UDP    10.0.1.18:138          *:*
UDP    10.0.1.18:1900         *:*
UDP    10.0.1.18:8086         *:*   this is BFME
UDP    10.0.1.18:51955        *:*
UDP    127.0.0.1:1900         *:*
UDP    127.0.0.1:51956        *:*
UDP    192.168.0.100:137      *:*
UDP    192.168.0.100:138      *:*
UDP    192.168.0.100:1900     *:*
UDP    192.168.0.100:51954    *:*

It's obvious that the game is selective about which interface it uses, which makes sense considering it needs to flood the user's LAN with discovery messages to determine the addresses of the other peers. But isn't a VPN supposed to provide a LAN through an internet connection? Why is the game choosing the old interface and not the higher-priority VPN interface? I'm thinking there must be some obscure setting that lets Windows configure the VPN network as a LAN; however I'm having the hardest time finding it.

Any help in the right direction is appreciated!

As an afterthought: I know the game is using NetBIOS functionality (I dumped its list of function imports). I also know (historically) that if any of the peers are not members of the same workgroup they are ignored. Could the issue I'm facing involve something to do with the NetBIOS configuration of the network?

0

I was able to solve this problem using a configuration option specific to the game in question (which I stumbled upon quite by accident with no small amount of luck). This allowed me to specify directly which interface the game should use. This is done by adding the following entry to the Options.ini file (located in %USERPROFILE%\AppData\Roaming\My Battle For Middle-Earth Files\):

IPAddress = x.x.x.x

Where x.x.x.x is the dotted-decimal representation of the IPv4 address of the interface you wish the game process to use.

I never figured out exactly why the game was ignoring the higher-priority virtual interface, so I conclude it must be a design flaw in the game's engineering and not something that can be configured in Windows.

It's also worth noting that I switched over to using OpenVPN instead of pptpd since it provided better link-layer support (i.e. I could bridge the server's virtual adapter to better handle broadcast frames).

0

This may also help on some machines. Whether it will work or not seems completely random, but installing a service is still easier than editing a config file every time you switch networks ;)

Something is truly screwed up in the way BFME handles networking, and sadly, the developer no longer exists and it's not open source, so we'll never know...

  • Welcome to Super User. External links can break or be unavailable, in which case your answer would not be useful. Please include the essential information within your answer and use the link for attribution and further reading. Thanks. – fixer1234 Jan 29 '17 at 18:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.