Dear Xipper and WeatherCat network troubleshooters,
Unfortunately I have never tried to setup Internet access so I can't help you. You appear to have provided all the necessary connections, so I hope someone else will spot something. In the meantime, you might look over the troubleshooting tips on the WeatherCat Wiki:
http://wiki.trixology.com/index.php?title=WeatherCat_Clients
Perhaps something there will help you out.
Cheers, Edouard
Thanks for the reference to the troubleshooting guide, at first I thought I had solved it. The documentation refers to configuring both TCP and UDP, my configuration lacked UDP as I have to write duplicate rules for everything to support it and just never did (though it did as-is previously). I added the UDP rules and one of the iOS clients worked...but then it stopped.
It seems that while the instructions imply that WeatherCat Server is listening on 5 ports on both UDP and TCP (49250-49254), it is in fact not actively doing so. In fact the service isn't listening on UDP at all..so the additional UDP rules are probably of zero value, but I'll leave them to save having to add them back if I am proven wrong. However according to the OS X IP stack:
lsof -n -i4TCP | grep Weather
WeatherCa 78214 username 11u IPv4 0x4593ab83e15788c5 0t0 TCP *:49252 (LISTEN)
WeatherCa 78214 username 82u IPv4 0x4593ab83e15788c5 0t0 TCP *:49252 (LISTEN)
The additional detail here is that, apparently on service startup WeatherCat Server actually only binds to one of the possible 5 TCP ports...and it seems that on restart it may pick a different one. I am guessing that the clients then have to try to connect to all 5 ports trying to find which one the server is actually listening on, and depending on how a given firewall implements these port forwarding it may take a long time for the "invalid" ports to timeout.
There has got to be a better way to do this, in my case it takes 2+ minutes for WeatherCat client to find the correct TCP port out of the 5 to use. This would even be worse if it was using 49254 as it would take that much longer for the client to walk the TCP ports.
What I don't understand is why it need so pick from a range of 5 TCP ports, rather than just using 49250 every time. Once the client does detect what TCP port is active it caches that detail and at least allows easy refreshing (for some period of time)...but having it take 2 minutes, or possibly 4 or 5 minutes, the "first time" seems rather costly in terms of mobile app experience.