PDA

View Full Version : Successful Connection Test, Players can't connect



Gwydion
May 11th, 2018, 13:23
Hey, guys. Good morning. So, I spent about an hour last night trying to help an FG GM get his table going so that outside players could connect to him. We created firewall rules with an AV that he has which I'm not familiar with (ESET premier), made sure his connection was private and not public, etc. The odd thing for me is he was getting a successful connection test, but I could not connect to his table using either his alias or his public ip address. We had him connect to my table just fine.

So, I'm at a bit of a loss on how else to help him. He might post a new thread here to give you more detail, but I wanted to see if anyone had ideas. I asked him to launch a game and then check canyouseeme.org to make sure the port is open, but if he has a successful test I assume it is.

I know this isn't much detail, but any ideas?

Zacchaeus
May 11th, 2018, 13:50
One possibility is that there have been reports that the IP address reported by FG on the start screen is not the actual IP address of the users computer. So I'd double check that the correct IP address is being used in the port forward rule.

ESET, like many other AV's has a manual mode. If you switch that on then start up FG it will ask if you want to allow it. Answering yes sets up all the correct rules for the program and the updater.

Halfront
May 11th, 2018, 15:33
You probably have already done this steps, but here goes:

https://support.eset.com/kb3112/

Not being able to "see" using his external IP seems to still point towards the port not open or not pointing in the right direction - to his personal PC IP.

Hope it helps...I'm not an expert but dabble a bit :)

Gwydion
May 11th, 2018, 15:59
You probably have already done this steps, but here goes:

https://support.eset.com/kb3112/

Not being able to "see" using his external IP seems to still point towards the port not open or not pointing in the right direction - to his personal PC IP.

Hope it helps...I'm not an expert but dabble a bit :)

Yep.. Really appreciate the link, but I did point him there and he created a port rule that seemed correct. Will keep trying. Thanks!

LordEntrails
May 11th, 2018, 16:46
I run ESET and have not had to setup a rule. But, that doesn't mean much.

I would check the IP. I've had it where FG doesn't report the correct IP. I think this happens when you have VPN connections created in your network center and they get a higher registry number than the standard network device. From a command/doc prompt run the following;
ipconfig /all

Look for something vaguely similar to this, and then the IPv$ address that goes with it.
23434

Gwydion
May 11th, 2018, 16:52
Thanks LordEntrails... Will do!

Trenloe
May 12th, 2018, 03:23
I asked him to launch a game and then check canyouseeme.org to make sure the port is open, but if he has a successful test I assume it is.
Did the GM actually do this? Did they get a successful report from canyouseeme.org?

It's a similar, but slightly different process - from the connection test to actually running a campaign ahve having port 1802 open all the time.

Silly question, but I have to ask as some new GMs haven't actually reallised this (thinking there is some cloud aspect to FG) - were they actually running a campaign, fully loaded up when the players were trying to connect?

Gwydion
May 12th, 2018, 14:37
Did the GM actually do this? Did they get a successful report from canyouseeme.org?

It's a similar, but slightly different process - from the connection test to actually running a campaign ahve having port 1802 open all the time.

Silly question, but I have to ask as some new GMs haven't actually reallised this (thinking there is some cloud aspect to FG) - were they actually running a campaign, fully loaded up when the players were trying to connect?

Not a silly question and yes, he definitely had his table up and a campaign loaded. I haven't been able to reconnect with him yet but I don't think he has checked the port with FG up and running. I definitely still want him to try that and will post here when he does.

esmdev
May 16th, 2018, 02:40
Microsoft pushed a major Windows 10 update today.

Since the update my player's haven't been able to connect yet I can connect from another PC on the local network.

I tried literally telling the firewall to let anything in and out on 1802 and still cannot connect from external PCs.

Gwydion
May 16th, 2018, 02:50
Microsoft pushed a major Windows 10 update today.

Since the update my player's haven't been able to connect yet I can connect from another PC on the local network.

I tried literally telling the firewall to let anything in and out on 1802 and still cannot connect from external PCs.

Did the update change your network to public from private? If so, maybe change it back and check?

LordEntrails
May 16th, 2018, 02:53
Microsoft pushed a major Windows 10 update today.

Since the update my player's haven't been able to connect yet I can connect from another PC on the local network.

I tried literally telling the firewall to let anything in and out on 1802 and still cannot connect from external PCs.
Check your connection properties. Windows Updates are known to change network settings from "Private" to "Public". You need your connection type to be "Private".

Trenloe
May 16th, 2018, 04:44
Since the update my player's haven't been able to connect yet I can connect from another PC on the local network.
If you can connect from another PC on your local network then the issue is more than likely with your port forwarding on your router - or something else changing in your ISP setup. Double, and triple, check your port forwarding on your router is correct. If it is, carry out tracert 8.8.8.8 from a command prompt and post the results here.

esmdev
May 16th, 2018, 13:58
The router settings were fine but the new windows defender firewall was getting in the way. While it added Fantasy Grounds automatically to the acceptable applications list, it didn't add it to the inbound rules until I manually stopped and restarted the firewall. Once the inbound rules were created it seems to be working fine.