Step 7 : Connect, test, fix glitches

Connecting your OpenVPN client

You now know the Public IP for your server : you will use it to connect your OpenVPN client.

Right-click your OpenVPN GUI, and "Edit Config" on your connection menu :

Remember the <OpenVPN Server Public IP or FQDN> placeholder at line 6 ? Replace it with your server's pubic IP that you copied previously in the EC2 Console :

Now close+save, right-click again and "Connect" !

You are now officially a geek : you're both, a VPN client AND a VPN operator, all in 1 person !

So bookmark this and come back after you have properly celebrated this major event in your life...

Several tests

Ok, now let's note and test a few things...

Your VPN client Private IP

We'll take a note of our VPN Private IP address, that you see in the OpenVPN balloon tooltip.

For this demo, we specified VPN network in our UserData as 10.10.10.0/24, so we are 10.10.10.6

Being the only client for your VPN server, you should always get the .6 VPN Private IP address in the network you specify in your UserData

Important : the server does Fantasy Grounds port forwarding for the .6 IP ONLY

Some pings

Let's open a new command prompt window and try a few commands :

ping 10.10.10.1 : pings the server's VPN private IP

Let's have a quick look at our server various IPs :

ping 172.31.10.45 : pings the server's ethernet LAN adapter private IP in AWS

ping 13.53.45.99 : pings the server's Public IP

Because we don't have a rule in our Security Group for that.

Let's add a rule to our Security Group : you can click its name in the left column of the EC2 instance Description tab, then go to the Inbound rules tab of the Security Group and click Edit, then Add Rule :

We want to authorize inbound ping requests, which are in reality ICMP echo requests, so our new rule will be typed "Custom ICMP rule - IPv4", with protocol "Echo Request", from source "0.0.0.0/0" :

Let's Save, then go back to our EC2 instance details to check it applies :

Fantasy Grounds

Now let's start Fantasy Grounds and create a test campaign with any ruleset and Start it.

Let's not play with the server alias : the Connection test will keep failing, that's expected !

I had to switch to my own FG machine for that, so i :

disconnected the test machine (W2012) i have used to show the latest OpenVPN (2.4.7, 64-bit) until now
"distributed" the my-fg-ovpn-dm01 set of VPN client files to my own machine
connected my own machine to the server, once again getting VPN IP = 10.10.10.6

This is a Windows 7 (FR) with an older OpenVPN (2.2.2, 32-bit), but I'm connecting fine :

So here I am, connected to the VPN server and with Fantasy Grounds eagerly waiting for players to connect :

Let's try this command in our command prompt :

netstat -ano | find "1802"

We can see above that our "GM FG" has the Windows Process ID 16100, and is listening to TCP 1802 on ALL IPs from ALL connected network adapters (the 0.0.0.0 on the left), including our VPN Private IP

Anatomy of a local connection

Now let's open a second Fantasy Grounds as a player on the same machine, and Join Game on localhost as Host address (localhost means "myself" and is the special private IPv4 address 127.0.0.1)

That works as expected : nothing fancy here, but if we retry our last command, we see how FG networking works :

the GM FG is still LISTENING on 0.0.0.0:1802 (Process ID16100, line1)
the player FG (line 3) :
- has Windows Process ID 15428
- It connected from 127.0.0.1 (using dynamic port 55536) to localhost=127.0.0.1 on port 1802, and the connection is still active (ESTABLISHED)
the GM FG has accepted the inbound connection (line 2) and "maintains the dialog" (ESTABLISHED) between his own 127.0.0.1:1802 and the "not-so-remote" player at 127.0.0.1:55536

The Player and GM FGs see each other both on the localhost 127.0.0.1 IP address, so they accept to work that way (otherwise we would have a license key conflict, as we'll soon witness).

Now let's disconnect our player FG and re-check :

We still see our GM FG listening, and the dynamic port that was used by our player FG (TCP 55536) is now in TIME_WAIT state, belongs to no process ID, and will be completely free to re-use by Windows within 4 minutes.

Connecting a player FG to the server public IP

This is all well and good, but what you want is players connecting to your server (its public IP, currently 13.53.45.99 in this demo) so that they auto-magically appear in your GM FG virtual table...

Let's try !

Houston, we have liftoff !

YES ! Our GM FG and Player FG were actually able to talk to each other...

...but they have DIFFERENT IPs and the SAME license key => LICENSE KEY CONLICT.

Your "REAL" players CAN now connect to your GM FG, using the server Public IP

And if you then retry our netstat command, you'll see all these connections arriving on your VN Private IP on port 1802, all coming in from the server Private IP / various ports.

EDIT : After some trial and errors, I was finally able to install the Demo version of Fantasy Grounds on my temporary Windows 2012R2 machine, even though I had some errors because it has no support for DirectX.

So here is an example of 2 connections, from 2 players with a Demo version of FG to my GM FG virtual table through the OpenVPN port-forwarding server :

The player connections seen on my GM FG machine :

Our GM FG sees ALL the "port-forwarded" player connections coming in :

from the server Private IPv4 address (172.31.10.45 in this demo) from various TCP ports
to our own VPN Private IP (10.10.10.6 in this demo) always on our TCP 1802 port

Note : I have FG Ultimate license so I can host any combination of licensed/demo players; if you have FG Standard then you can host 1 demo or N licensed players. This is the FG licensing scheme.

What if it fails ?

...Now recheck everything for your GM machine's Barriers 1-3, remembering that FG inbound connections will come to your GM FG through the VPN connection, which Windows (rightfully) considers to be a DIFFERENT network than your usual home network.

=> for Windows 10, you have to mark the VPN connection as PRIVATE !

=> don't forget to open some doors in all your firewall-like thingies...you'll probably need to do so for both :

your VPN private IP network (10.10.10.0/24 in this demo)
AND the server Private IPv4 in your AWS VPC (172.31.10.45 in this demo)

OpenVPN : CRLF ? Check the startup log of your OpenVPN server instance

In the Instances section of the EC2 Console, use this right-click contextual menu :

That should give you (several minutes after the instance is launched) something like this...

After 450 to 500 lines, if you encounter the following error message, it means your fgovpn001-init.sh was saved with the CRLF mode for End-Of-Line control characters instead of LF :

In this example, because of a rogue CR character (^M) at the end of the very first line, the init script did NOT execute AT ALL, so OpenVPN is not even installed on your (useless) virtual server !

In the above example, don't be confused by the following line 502 ("UserData script finished").
The very last thing that the UserData script tried to do was running fgovpn001-init.sh (line 499), so the error actually comes from that file, not from the UserData script (it has been cleansed of any CRs by importing it in the web editor in the AWS Console).

=> Correct the error by saving fgovpn001-init.sh in LF mode in your my-fg-ovpn-s3 local sub-folder, re-transfer the file to S3 to overwrite the one you previously stored, Terminate (=destroy) your current instance (right-click / Instance State / Terminate) like shown in Step 8, and then launch a brand new one !

...finally, if you still can't make this work, then ask for help with the links at the beginning of this document...

A little fix to our AWS Launch Template

T2/T3 Unlimited mode : Enabled

This is not a setting we want for our use case, as it may introduce costs (though that is very unlikely, OpenVPN using a very low percentage of CPU).

Anyway, this came out because in the AWS region we used, we did not have the usual "free tier elligible" t2.micro instance type but the t3.micro instead, and i found this note in AWS EC2 documentation which explains this unexpected (at least for me) setting :

Just to be sure, we'll disable this setting and that will give us an opportunity to experiment with creating a new version of our Launch Template.