22 lines
4.2 KiB
Plaintext
22 lines
4.2 KiB
Plaintext
|
@@META charset UTF-8
|
||
|
|
@@META name viewport content width=device-width,initial-scale=1.0
|
||
|
|
@@TITLE TAP VPN for Remote LAN Gaming
|
||
|
|
@@CSS ../css/main.css
|
||
|
|
# The Jerks
|
||
|
|
## Blog
|
||
|
|
[Back to blogs](https://www.thejerks.club/blog.html)
|
||
|
|
|
||
|
|
### TAP VPN for Remote LAN Gaming
|
||
|
|
@@BLOGPOSTTITLE TAP VPN for Remote LAN Gaming
|
||
|
|
@@BLOGPOSTDATE 1706943051
|
||
|
|
|
||
|
|
#### Introduction
|
||
|
|
I started hosting LAN parties long ago, when I was in high school. Our favorite games to play were from the 2000s. Back in those days, I guess the average gamer was considered enough of an idiot that they wouldn't know what an "IP address" was, so having direct-connect capabilities for games back then was hit and miss. Either this, or somehow they reasoned that direct-connect capabilities increased piracy. In any case, some games were excellent for LAN multiplayer, like all the early Call of Duties (anything before MW2) which exposed a console that allowed direct connection. Others were awful, like Star Wars Battlefront II which depended upon server discovery. These games that depended on server discovery had the additional egregious sin of only scanning the highest priority network interface instead of all the network interfaces for games, meaning that if you somehow were left littered with network interfaces when you were e.g. messing around with virtual machines, one of these unused interfaces might have been the one that was scanned. The scanning itself happened via the now *deprecated* broadcast address - sending packets to 255.255.255.255, letting the router forward these packets to all of its clients, and answering any replies.
|
||
|
|
At some point we all grew up, but we still wanted to play these games even though we were scattered across the country. Gamespy's 2014 shutdown killed online multiplayer for many of the games we played, and publishers not wanting to pay for the servers killed the rest. If a game was beloved enough, people would reimplement master servers for these games (e.g. [swbfspy](https://info.swbfgamers.com) for Battlefront I and II). However, for various reasons including my zealousness for where my internet traffic goes - why go through a master server and a public server when all I want to do is play with my friends? - I wanted to get LAN multiplayer over a VPN working for these games.
|
||
|
|
|
||
|
|
#### The Problem
|
||
|
|
I already use a VPN to keep in touch with my friends and play video games that allow *direct connection* to hosts, but this is an OpenVPN TUN configuration. As mentioned before, these older games use the broadcast address 255.255.255.255 to scan for games. OpenVPN allows you to create a TUN (create essentially an isolated virtual network with the VPN server acting as a router) or a TAP (essentially graft clients into the one of the networks to which the host is connected by bridging the virtual TAP interface with an interface) VPN. TUN is much easier to set up and recommended by pretty much everyone on the internet for what we were doing, which is why we went with this. However, TUN also works at a higher layer of the OSI model that is incapable of handling broadcast addresses so when my game sends out requests to 255.255.255.255 these packets are essentially just ignored. TAP does not have this issue though. In this post, I will be bridging the virtual TAP interface with the server's interface to the internal network, which is almost universally discouraged online for security reasons (at least without firewall rules for isolating traffic). For this reason, we only put this TAP VPN up on an ad hoc basis, bringing it up when we want to game and tearing it down when we are done. Eventually, we will switch to using an unused interface on the server. In addition to this problem, we also need to make sure that 255.255.255.255 is routed through the TAP interface.
|
||
|
|
Note: networking is one of my weakest points in computing, so this explanation of TAP/TUN might not be 100% correct. For the purposes of this post it should suffice.
|
||
|
|
|
||
|
|
#### The Setup
|
||
|
|
We assume that the internal network for the server is on the 192.168.1.x subnet which is pretty standard. When grafting in disparate clients to this network, we can reserve a chunk of this subnet to these clients. In this case, we will set 192.168.1.240 through 192.168.1.254 as the IPs assigned to clients connecting to the VPN. It is
|