More > JRiver Media Center 24 for Windows
Feature Request: Improved SSL support
mwillems:
+1 for allowing the remotes to use SSL--
Also if you're revisiting the SSL connection code in the remotes, please support the use of fully-qualified domain names in the remotes instead of just IPs; one of the joys of having a cert is that you can use dynamic DNS to abstract your IP away behind a domain name and currently I think the character limit in the address space on Gizmo and JRemote is all that prevents it from working (I think).
michael123:
+1
glynor:
--- Quote from: mwillems on March 18, 2018, 08:25:31 am ---Also if you're revisiting the SSL connection code in the remotes, please support the use of fully-qualified domain names in the remotes instead of just IPs; one of the joys of having a cert is that you can use dynamic DNS to abstract your IP away behind a domain name and currently I think the character limit in the address space on Gizmo and JRemote is all that prevents it from working (I think).
--- End quote ---
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
mwillems:
--- Quote from: glynor on March 19, 2018, 08:26:27 am ---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
--- End quote ---
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.
glynor:
--- Quote from: mwillems on March 19, 2018, 05:55:46 pm ---Glynor, on jremote for android it doesn't work at all here, it just claims the ip address isn't valid.
--- End quote ---
I've only ever used it on iOS, so Android could well be broken.
I remember in early builds (before JRiver owned it) you could only input numeric IP addresses, and I complained, and lespaul fixed it. I've used my FQDN for iOS JRemote ever since. To be clear, in the iOS version, you just enter the address and port (no HTTP or HTTPS prefix of any kind). JRemote for iOS, however, does NOT (to my knowledge) support TLS, which is a bummer.
They should fix both things. ;D :P
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version