Using a FQDN works fine on JRemote. I have a Dyn FQDN for my home network, and that's how I connect to it.
You do need to have a router that can do Full NAT if you want to use the same server entry inside your LAN as you do outside it, though. Because that FQDN will resolve to your external WAN address even when you are inside your network, and routing will not work through NAT with simple port forwarding if the traffic goes to the WAN address for devices inside the network. Full NAT fixes this by changing the destination "bi-directionally" (basically, the rule sends the traffic to the server's internal IP if the origination is internal, and still does the port forwarding if the origination is external).
Or, if you only run a single external network service like this, or if all services run on the same machine, you can "hack it" by just changing the IP address that the FQDN resolves to for internal machines. If the machines are permanently internal, you could just use a Hosts file to do it. Though that's not likely for mobile devices, so you probably need to have a router that can do DNS forwarding and provide internal DNS.
Here's an example of how to handle this from Sophos using their UTM firewall:
https://community.sophos.com/kb/en-us/115191
Glynor, on jremote for android it doesn't work at all here, it just claims the ip address isn't valid. The exact same FQDN/port combo works on the phone's browser (it goes straight to panel) and both results are the same inside or outside the local network, so its not a split dns or NAT issue. I run pfsense on the router and it provides dns services to all my devices reliably for panel so I know the jriver server is reachable at that FQDN/port combo.
With gizmo, my FQDN is longer than the hard-coded character limit in the app (my FQDN is too long and I can't enter it all), I can't even get that far. That's what I meant about support possibly just being about removing the character limit. I have no problem with NAT or split DNS with anything else that interfaces with my FQDN so I assumed the apps just lacked support.
If you can confirm that you've got jremote for android (as opposed to ios) working with a FQDN, I'll go back to the drawing board and try again. Do you include the https:// header at the front? Do you use a nonstandard port? Do you use authentication? Just trying to id why it might be failing here and not for you.
Thanks for chiming in on this, I raised this in the original SSL thread and couldn't get any thoughts from anybody.