Another connection issue thread... sorry

OK, I've tried to figure this out on my own but am at a loss...
FG has been working fine for me for years, and in fact was working fine two weeks ago. Last night when attempting to host a game, the players couldn't connect and I am getting a connection test failure. No new hardware or software. I connect to a Google Wifi network connected to a cable modem. All port-forwarding is still in place, and my network is still set to private. IP address has not changed.

What should my next step be? Thanks.

- E

When things work and then don't there are three things to check. The first is that your network is still set to private (done); the second is make sure that your internal IP address hasn't change and thus negating your port forward rule; and third refresh all of your antivirus rules (that is delete all of them and make new ones - especially if you use Windows Defender or some other ones).

Oh, and sometimes just rebooting your router is all that it takes.

Huh, apparently going into the cable modem settings (not the Google Wifi settings), and switching on DMZ+ mode fixed the issue. I'm not sure I understand why, as Fantasy Grounds was already added to the list of allowed apps. But I'm not a computers person, really, just a dabbler.

Be careful, putting yourself in DMZ+ mode is asking for trouble, especially since you're broadcasting your external IP right here on the public internet. It is worth trying to figure out why you were having trouble. At the very least, put it back out of DMZ+ mode when you're not running a game.

It's very strange that the timeout was happening outside of your network. That last address it times out at seems to be an AT&T block, still, so you might want to try again to see if it was just a transient issue that night. If it still fails, talk to AT&T.

Quote:

---

Originally Posted by slitherrr

It's very strange that the timeout was happening outside of your network.

---

It's not uncommon for Public Internet devices to the set to not respond to pings. I get the same result when I tracery to 8.8.8.8 - so it looks like the last hop doesn't respond to pings. The fact that the tracert continues to the next step and gets a response from 8.8.8.8 shows that it's not actually an issue - the device that doesn't respond to pings still routes data packets to/from the destination.