Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[res80]

It is great that we can have SSL support on the MC server, however it is still missing for JREMOTE, so that I cannot close the port 52199 on my router, because then jremote would lose its non-ssl encrypted access to my server

Please add this as soon as possible.
Thanks,
Ruediger

[RD James]

+1

[Cinelder]

+1

[TheShoe]

+1

[AndrewFG]

+1

[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]

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).

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]

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.

[glynor]

Glynor, on jremote for android it doesn't work at all here, it just claims the ip address isn't valid.

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. 

[hoyt]

Yes!!

https://yabb.jriver.com/interact/index.php/topic,110982.msg786871.html#msg786871

I do see that hendrik said this was coming "later" in June of 2017.  I find it disappointing that this didn't get more priority.  I know the server is required, and clients were easy next, but the obvious reason to use SSL is to encrypt your connection on unknown networks.  We clearly use the mobile clients on other networks far more than we do an MC client.