Remote access to frontview unusably slow - what can be done?

Do you have someone in the US at the local site? It might be good to confirm that they can access frontview correctly (and that you don't have a failing NAS).

There is no need to forward port 80, I suggest it is better that you block it (and only use https for remote access). If you access your shares over port 80, you are sending your logon credentials and all your data unencrypted, which is a significant security risk. Also I would personally use the alternative https port number feature in the NAS, and forward the alternative port instead of 443. Though of course this requires frontview access to configure...

StephenB wrote:
Do you have someone in the US at the local site? It might be good to confirm that they can access frontview correctly (and that you don't have a failing NAS)...

Yes they can access it locally - it comes up in the normal 2-5 seconds.

Ok. I think I would try switching from 443 to a different port number (forwarding the new port number in the US router, and adding it as port 2 in the https NAS configuration). For instance, if you used 50443 as the second port, your browser URL would change to https://mydomain.com:50443/admin/

StephenB wrote:
Ok. I think I would try switching from 443 to a different port number (forwarding the new port number in the US router, and adding it as port 2 in the https NAS configuration). For instance, if you used 50443 as the second port, your browser URL would change to https://mydomain.com:50443/admin/

Hi - Verizon's Actiontec MI424WR router allows for alternative http & https ports, which we set up, but made no difference, unfortunately.

StephenB wrote:

Do you have someone in the US at the local site? It might be good to confirm that they can access frontview correctly (and that you don't have a failing NAS). There is no need to forward port 80, I suggest it is better that you block it (and only use https for remote access). If you access your shares over port 80, you are sending your logon credentials and all your data unencrypted, which is a significant security risk. Also I would personally use the alternative https port number feature in the NAS, and forward the alternative port instead of 443. Though of course this requires frontview access to configure...

Can I trouble you for more specific instructions for a noob? A little about the port forwarding, but the front view access remotely.
Also, I am just setting up my nas and do have port 80 forwarded (to test - understand security risks and will change later on) and also have port 443 forwarded to the NAS. When I log on remotely (with IP address or with my domain name assigned by TZO - option for linksys router) with HTTP or HTTPS, I connect (I think) but get a blank page and it appears to be stuck in a loop of trying to load something from the server (IE reads "connecting") - but nothing comes up. Suggestions?

kc1 wrote:
Hi - Verizon's Actiontec MI424WR router allows for alternative http & https ports, which we set up, but made no difference, unfortunately.

I use the same router (also a FIOS customer). I have remote administration of the router turned on, and set for the normal port 443. I use a totally different port for https to the ReadyNAS (actually 3 different ports, one for each of my Readynas systems). All are forwarded in the actiontec to the appropriate NAS, and each NAS has its port configured as the "second port" on the https configuration screen in frontview. I travel internationally fairly regularly, and have always been able to run frontview remotely.

If you have the remote management on the actiontec configured for port 80 and port 443, then you are giving the router conflicting instructions - telling it to forward ports 80 and 443 to the NAS, and at the same time telling it to allow remote management of the router itself on the same ports. I am not sure what it will do in that case.

I suggest you configure the NAS to use a completely different second port for https, and forward that in the actiontec (matching my approach, which I know works).

Jjnsgy wrote:

Can I trouble you for more specific instructions for a noob? A little about the port forwarding, but the front view access remotely. Also, I am just setting up my nas and do have port 80 forwarded (to test - understand security risks and will change later on) and also have port 443 forwarded to the NAS. When I log on remotely (with IP address or with my domain name assigned by TZO - option for linksys router) with HTTP or HTTPS, I connect (I think) but get a blank page and it appears to be stuck in a loop of trying to load something from the server (IE reads "connecting") - but nothing comes up. Suggestions?

I suggest you start a new thread on your problem, since having two conversations on this thread will be very confusing.

StephenB wrote:

kc1 wrote: ...If you have the remote management on the actiontec configured for port 80 and port 443, then you are giving the router conflicting instructions - telling it to forward ports 80 and 443 to the NAS, and at the same time telling it to allow remote management of the router itself on the same ports. I am not sure what it will do in that case. I suggest you configure the NAS to use a completely different second port for https, and forward that in the actiontec (matching my approach, which I know works).

Mine in the US is set to port 5151. Just times out, as described, hile it's loading the frontview page. As a test I tried pointing it to the extplorer add-on, but the same thing happens - starts to load the page, and then times out. I've tried various other port permutations, but it doesn't seem to make any difference. The tracerts show it timing out on the last 2 hops at the verizon end.

kc1 wrote:
Mine in the US is set to port 5151. Just times out, as described, while it's loading the frontview page. As a test I tried pointing it to the extplorer add-on, but the same thing happens - starts to load the page, and then times out. I've tried various other port permutations, but it doesn't seem to make any difference. The tracerts show it timing out on the last 2 hops at the verizon end.

If you enable ICMP response in the US actiontec, does the tracert show no response at the US router? Sometimes tracert is misleading, since some intermediate devices are intentionally set to ignore ICMP.

If you are getting packet loss within the verizon network, you probably need to raise the issue with them.

StephenB wrote:
If you enable ICMP response in the US actiontec, does the tracert show no response at the US router? Sometimes tracert is misleading, since some intermediate devices are intentionally set to ignore ICMP. If you are getting packet loss within the verizon network, you probably need to raise the issue with them.

I'll ask my friend to check if ICMP response is set.

This is typical of what I get:

 1    <1 ms    <1 ms    <1 ms  192.168.1.254
 2     6 ms     6 ms     6 ms  217.32.146.171
 3    10 ms     6 ms     6 ms  217.32.146.238
 4     7 ms     7 ms     6 ms  213.120.177.90
 5     9 ms     9 ms     8 ms  213.120.176.74
 6    14 ms     7 ms     7 ms  213.120.176.182
 7     8 ms     7 ms     7 ms  acc2-10GigE-0-2-0-4.l-far.21cn-ipp.bt.net [109.159.249.225]
 8    25 ms    10 ms    23 ms  core2-te0-0-0-0.ealing.ukcore.bt.net [109.159.249.153]
 9    11 ms     8 ms     7 ms  transit2-xe0-1-0.ealing.ukcore.bt.net [194.72.17.82]
10    17 ms    12 ms    14 ms  t2c4-xe-9-0-0.uk-eal.eu.bt.net [166.49.168.49]
11    36 ms    28 ms    21 ms  xe-9-3-0.edge3.London2.Level3.net [212.187.201.125]
12    10 ms    21 ms    14 ms  ae-32-52.ebr2.London2.Level3.net [4.68.117.62]
13     8 ms     8 ms    10 ms  ae-3-3.ebr1.London1.Level3.net [4.69.141.189]
14     8 ms     9 ms     8 ms  vlan101.ebr2.London1.Level3.net [4.69.143.86]
15    77 ms    77 ms    77 ms  ae-41-41.ebr1.NewYork1.Level3.net [4.69.137.66]
16    81 ms    81 ms    86 ms  ae-4-4.ebr1.NewYork2.Level3.net [4.69.141.18]
17    84 ms    77 ms    77 ms  ae-1-100.ebr2.NewYork2.Level3.net [4.69.135.254]
18   101 ms    98 ms   123 ms  ae-2-2.ebr1.Chicago1.Level3.net [4.69.132.65]
19   107 ms    99 ms   110 ms  ae-6-6.ebr1.Chicago2.Level3.net [4.69.140.190]
20   100 ms    99 ms    98 ms  ae-1-51.edge4.Chicago3.Level3.net [4.69.138.134]
21     *        *        *     Request timed out.
22   123 ms   100 ms   103 ms  0.ae3.CHI01-BB-RTR2.verizon-gni.NET [152.63.64.242]
23     *        *        *     Request timed out.
24   123 ms   119 ms   118 ms  pool-173-48-119-43.bstnma.fios.verizon.net [target IP]

My friend says Verizon have been no help whatsoever.