Step 7 : Connect, test, fix glitches
Last updated
Was this helpful?
Last updated
Was this helpful?
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...
Ok, now let's note and test a few things...
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
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
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 :
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 !
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 :
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
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.
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 !
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 :
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.
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).
...finally, if you still can't make this work, then ask for help with the links at the beginning of this document...
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.
We go to the Launch Templates section of the EC2 Console and click "Create launch template" again, but this time we :
select Create a new template version
select our existing template
enter a version description
select the existing version as source
Then we go to the bottom, expand Advanced details and switch the T2/T3 Unlimited setting to Disable :
And now we can click the final "Create launch template" button :
Here we are :
Now let's make this new version the default version of our Launch Template, because the original one is currently still the default one :
So we check the line is selected (blue square on the left) and use the Actions button :
Nothing mysterious there...
Finally we're done :
You'll see a log flowing in a window.... ...aaaannnnndddd...
Hummm...The server does not reply to our ping on its Public IP. Why ?
Because we for that.
Let's retry our ping on the public IP to check we have the replies...ok
Aarrgghh !!!...Well, actually : Yeah !!! It works !!! (though it looks disappointing...)
What ? How ? When ? Where ? You have a real failure ? Like this one with a "player" FG ? Or worse, you can't even connect with your OpenVPN client to your shiny new server ?
Ok,10 seconds to ...
=> 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 , and then launch a brand new one !
A little glitch caught my when we launched our server, that you'll find just below the pink highlight for Source/dest. check on the screenshots of the EC2 console :
