Fantasy Grounds - Port Forwarding - Transparent Op
  • Fantasy Grounds - Port Forwarding and a "transparent" OpenVPN setup
  • General
    • Introduction - F.G.Comms
    • GM's machine barriers
    • Internet connection barriers
    • Some NO-GO Situations
    • VPN solutions
  • Proposed Solution
    • "Transparent" OpenVPN-based Port Forwarding
    • Tools
    • Amazon Web Services
    • Setup process overview
  • Local setup - Step-by-step
    • Step 0 : Preparation
    • Step 1 : OpenVPN + Easy-RSA & "new-PKI"
    • Step 2 : Create your own PKI
    • Step 3 : Setup OpenVPN connections
  • AWS Setup - Click-by-Click
    • Step 4 : Your AWS environment
    • 4.1-Creating the IAM Role
    • 4.2-Choosing the AWS Region
    • 4.3-Creating the S3 bucket
    • 4.4-Virtual Private Cloud - Default VPC
    • 4.5-Creating an AWS Key Pair
    • 4.6-Creating an AWS Security Group
    • 4.7-Filling the bucket
    • 4.8-Building the Launch Template
  • Transfer & First Test
    • Step 5 : Transfer to S3
    • Step 6 : Launch time !
    • Step 7 : Connect, test, fix glitches
    • Step 8 : Destroy/"Terminate" after use
  • Use your server
    • Regular Usage Pattern
  • Simultaneous FG games / 1 VPN Server
    • Lifting the "1 GM at-a-time" restriction
    • FGU vs. FGC networking
    • VPNs for both FGC + FGU (LAN mode)
  • Upgrading our setup for "N-at-a-time", FGC/FGU
    • Untitled
  • Appendixes
    • Acronyms and definitions
    • AWS acronyms
    • AWS admin user + API access key
    • AWS, DNS, DDNS, CRL...
    • Possible (?) developments
  • Links
    • Fantasy Grounds Web
    • Fantasy Grounds Discord
    • FG College Web
    • FG College Discord
    • FG College KB
    • Our "EU" Discord
    • OpenVPN
    • AWS
Powered by GitBook
On this page
  • FG "Unity"
  • Multiple concurrent GMs
  • Multiple Public IPs
  • Redirecting on the player side
  • Other ideas...
  • ...are welcome !
  • Discord helper bot
  • useful tools ???
  • Other ways of using OpenVPN

Was this helpful?

  1. Appendixes

Possible (?) developments

PreviousAWS, DNS, DDNS, CRL...

Last updated 4 years ago

Was this helpful?

FG "Unity"

This is unknown territory for me and will stay so until at least I get the beta, and more probably until the official launch of the product.

There should remain a virtual table access/communication mode of the same kind as FG "Classic", but also some much awaited "MMO-like" features like a lobby, etc.., supposedly freeing the GMs from the port forwarding issue.

That would probably mean that SmiteWorks maintain some kind of central routing platform (?) handling inbound communications for the live virtual tables from GMs+Players ???

That would also probably need to be globally deployed, to be viable on a worldwide scale, and that makes me wonder about running costs ???

Enough what-ifs !

I'm ignorant on what can actually be done with Unity network features, so I'll just have to look at the new FGU networking when I can test the beast...

Multiple concurrent GMs

One drawback of this setup is under-utilization : it uses a complete server virtual machine for only 1 GM at a time, because the server only has 1 public IPv4 address (to avoid costs). With the smallest possible virtual server at AWS (currently 1 virtual processor + 512MB RAM), the CPU is used less than 0.5% ! What a waste !

Multiple Public IPs

A [fixed] public IPv4 address is now like a magical item giving [+2]+1 to all abilities...

While using multiple public IPs is an option, it requires using "Elastic IP Addresses" (EIP) at AWS, which are fixed public IP addresses that are reserved for your account when allocated, but they are free ONLY when attached to a RUNNING server as the ONLY public IP for that server :

  • the first EIP attached to a running virtuall server is free

  • an additional EIP attached to the same running server will cost $0.005 /Hour +VAT

  • an unattached EIP, or an EIP attached to a stopped server will also cost $0.005 /Hour +VAT

That means (as of june 2019) for an unused/second EIP : around $4.4 /month, VAT included.

Also, an EIP is attached to a network interface, of which there can be only a limited number per server depending on its type, and of course the smallest/cheapest servers can only have 2 interfaces => a maximum of 2 concurrent GMs that could be reached from players on EIP1/1802 + EIP2/1802.

And finally, the "create on use, destroy when finished" strategy we use for the server would leave the EIP(s) unattached => billable...

Redirecting on the player side

So, the only way i see to "mutliplex" is on the client side (i.e. the player machine), to introduce proxying and redirect an outbound connection to TCP 1802 towards another (IP+)port. The best way to do that for a player is to use the localhost (127.0.0.1) address as the connection target, and intercept 127.0.0.1/TCP 1802 inbound connections to redirect them.

lightweight, simple, NO permanent setting left behind...

This is what I tested :

We can have concurent GMs connected to the VPN server, each with his own fixed VPN private IP PrvIPnn (using the GMs' certificate identity and the ccd="client config directory" feature of OpenVPN) and with corresponding PrvIPn-specific port forwarding rules installed in the VPN server :

  • GM1 always gets private IP PrvIP1 in the VPN when connecting to OpenVPN (configured in ccd)

  • GM2 always gets private IP PrvIP2 in the VPN when connecting to OpenVPN (configured in ccd)

  • the server listens to ports p1 and p2 (ex: 18021 and 18022) on its single public IP : PubIP

  • 1 forwarding for PubIP/p1 <=> PrvIP1/1802 for GM1

  • 1 forwarding for PubIP/p2 <=> PrvIP2/1802 for GM2

So the problem is to find a way, for a session (NOT permanently : we don't want to "lock" players to a specific GM and we absolutely don't want to modify anything in the players' machine), for :

  • players A, B, C to have their FG connect to PubIP/P1 to get into GM1's virtual table

  • players X, Y, Z to have their FG connect to PubIP/P2 to get into GM2's virtual table

Still only 1 public IP but 2 different TCP ports => 2 FG virtual tables at a time, and that can be generalized to a higher number than 2 of course...

  • config line for players A, B, C : 127.0.0.1 1802 (PubIP) (p1)

  • config line for players X, Y, Z : 127.0.0.1 1802 (PubIP) (p2)

Then after the session, the players kill their rinetd / close their command prompt window.

Done !

Unfortunately that defeats our "transparency" objective :

Other ideas...

Discord helper bot

useful tools ???

Diag.tools, common commands etc...

Not sure it would be useful : there are already sooo many examples everywhere.....

Other ways of using OpenVPN

If interest appears for "own closed VPN" for example...

However we have one issue for FG "Classic" : FG "Join Game" connects exclusively to TCP 1802 on the target server, and I didn't find anything where you can override this behaviour, and since with only 1 public IP, there can be only 1 "listener" on TCP 1802 for inbound connections...

The solution exposed below is still valid, but I think the new section provides a more elegant/easy to use solution.

It relies on the ability to use another TCP port than 1802 when launching FG "Classic", which I finally discovered after 2 years using the program...

I have successfully tested setups with the old utility with a very simple 1-line config file, and that is the "best" (least bad) solution i found for Windows :

It is also achievable with netsh interface proxyport on modern versions of Windows, but it is very awkward, needing Windows admin access and creating a permanent redirect that you have to delete afterwards...

That can be achieved with the players running in a background command prompt window before they connect to their GM by using localhost as the "host address" : their "player FG" will connect to 127.0.0.1:1802 and rinetd will redirect that according to its config :

Even if it's not a VPN client install, it's still a specific config to manage for the players (1 small exe + a 1-line config file to keep somewhere, and run when needed), so the solution becomes "NOT transparent" for the players.

That could be acceptable for a regular group (GM + Players) for a whole campaign...

...But it would not be viable for ephemeral things like 1shot games, FGC classes, etc...

So : no satisfying (transparent) free workaround on my side for the moment...sorry !

...are welcome !

After I finish this exhausting doc writing exercise, I plan to build a small basic operations admin bot for my own OpenVPN + Discord : launch, terminate, start, stop, reboot + getting the public IP (+updating DNS name in Route53)

This will be based on ideas I found while prowling the ...............and all unmentionable places where a role playing dino can lurk...

💩
🤪
👿
👿
❓
😡
😁
🥵
Lifting the "1 GM at-a-time" restriction
rinetd
rinetd
FG forums
GitHub
Discord.js
their Guide
Discord Dev portal