Hi, not sure if this is the right place for this question, but here goes:How can I improve or even influence the speed of accessing a remote NAS from across the Atlantic? I'm trying to set up a backup between an Ultra 4 Plus and NV+ on either side of the Atlantic but accessing Frontview is the first problem - it won't fully load (just the background).At my end the connection is 37.4mbps down and 8 up, at the other end it's 22.4 down and 23.7 upA tracert shows:Tracing route to pool-108-20-43-198.bstnma.fios.verizon.net [108.20.43.198]over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.1.254 2 6 ms 6 ms 6 ms 217.32.146.171 3 6 ms 7 ms 6 ms 217.32.146.222 4 7 ms 6 ms 7 ms 213.120.177.106 5 7 ms 6 ms 6 ms 213.120.176.74 6 7 ms 7 ms 7 ms 213.120.176.182 7 7 ms 7 ms 6 ms acc2-10GigE-0-2-0-5.l-far.21cn-ipp.bt.net [109.159.249.227] 8 12 ms 10 ms 11 ms core2-te0-14-4-0.ealing.ukcore.bt.net [109.159.249.143] 9 7 ms 7 ms 7 ms transit2-xe1-1-0.ealing.ukcore.bt.net [62.6.200.142] 10 7 ms 7 ms 7 ms t2c4-xe-9-1-0.uk-eal.eu.bt.net [166.49.168.53] 11 8 ms 8 ms 8 ms xe-8-0-0.edge4.London2.Level3.net [212.187.192.61] 12 18 ms 17 ms 17 ms ae-31-53.ebr1.London2.Level3.net [4.68.117.94] 13 8 ms 15 ms 17 ms ae-1-100.ebr2.London2.Level3.net [4.69.141.118] 14 8 ms 8 ms 8 ms ae-3-3.ebr1.London1.Level3.net [4.69.141.189] 15 9 ms 8 ms 8 ms vlan103.ebr2.London1.Level3.net [4.69.143.94] 16 77 ms 77 ms 77 ms ae-42-42.ebr1.NewYork1.Level3.net [4.69.137.70] 17 77 ms 77 ms 77 ms ae-4-4.ebr1.NewYork2.Level3.net [4.69.141.18] 18 86 ms 77 ms 77 ms ae-1-51.edge2.NewYork2.Level3.net [4.69.138.195] 19 76 ms 76 ms 76 ms Verizon-level3-2x10g.NewYork.Level3.net [4.68.62.42] 20 76 ms 76 ms 76 ms 0.ae1.XL4.NYC1.ALTER.NET [152.63.18.233] 21 93 ms 93 ms 93 ms xe-4-1-2-0.NY5030-BB-RTR1.verizon-gni.net [130.81.17.122] 22 * * * Request timed out. 23 93 ms 94 ms 94 ms pool-108-20-43-198.bstnma.fios.verizon.net [108.20.remote.ip]Trace complete.What can be done to achieve a workable speed

Frontview is not designed for access from a remote site.Do you have a PC you can remotely login to and use to access Frontview?

I have set up / forwarded an alternate https port, and I frequently log in with frontview remotely (including when I am overseas). Generally I have not had any issues, though of course the speeds are slower. I also use fios. So it is a bit surprising that you aren't able to.Even if you have fast connections at both locations, you are still subject to cross-congestion / slowdowns on the full wide area connection path (across the Atlantic for instance). So your speeds will vary, and connections can time out.Therefore, for file transfers I would suggest FTP, (and also suggest enabling upload resume on the NAS). Then if a connection drops, the transfer can automatically resume, so it is much more robust than http. (Backup with FTP may not be so easy, since incremental FTP is more-or-less deprecated).If you have VNC or remote desktop installed, you can also connect to a PC at home base, and use its browser to connect to frontview. I don't know if that would be any faster though (and wouldn't recommend trying to do file transfers that way).

mdgm wrote:Frontview is not designed for access from a remote site.Really? I access the admin functions on my NVX all the time. Just can't seem to get a fast enough connection to the remote NV+mdgm wrote:Do you have a PC you can remotely login to and use to access Frontview? NoStephenB wrote:I also use fios. What's that?StephenB wrote:for file transfers I would suggest FTP All I'm trying to do with frontview is setup an rsync backup to pull data from the local NAS from a remote NAS...which I thought was the whole idea with these boxes?StephenB wrote:Even if you have fast connections at both locations, you are still subject to cross-congestion / slowdowns on the full wide area connection path What can be done to deal with or improve this, so that it at least works? Surely I can't be the only one with a ReadyNAS on both sides of the Atlantic?

kc1 wrote:StephenB wrote:I also use fios. What's that?Your traceroute indicates that your US ISP is Verizon Fios (pool-108-20-43-198.bstnma.fios.verizon.net)kc1 wrote:StephenB wrote:for file transfers I would suggest FTP All I'm trying to do with frontview is setup an rsync backup to pull data from the local NAS from a remote NAS...which I thought was the whole idea with these boxes?You can also choose FTP for backup, though I've not tried it myself. I was thinking more about remote file access than backup when I made the FTP suggestion.kc1 wrote:StephenB wrote:Even if you have fast connections at both locations, you are still subject to cross-congestion / slowdowns on the full wide area connection path What can be done to deal with or improve this, so that it at least works? Surely I can't be the only one with a ReadyNAS on both sides of the Atlantic?Large companies make their own deals with ISPs that have performance guarantees ("service level agreements"). The rest of us get to use best-effort internet service, so we have to live with what we get. In your case, the problem could be with your UK or US providers, or Level3 (which is doing the London to NY hop). What usually happens if you complain is that the service providers all point to someone else. The speed limit is not because of the ReadyNAS, it is certainly faster than your wide area network connections.Are you attempting to connect with ReadyNas remote??? I don't think that would be fast enough for a backup (and it is not intended for that). Assuming no: if you never get a functional frontview connection to the remote system [from any remote site], you could have a port forwarding problem on the US site's router. And you will also need to configure proper port forwarding for rsync (which router depends on where the backup job is being run).Your traceroute provides latency information, but doesn't give any idea about throughput. The "Request timed out" hop is almost certainly not an error - that router is likely configured to ignore ping requests. Maybe you could try making some reasonable size files transfers (either with rsync or FTP), and post the measured transfer speeds and sizes?

Thanks for your detailed reply Stephen...StephenB wrote:Are you attempting to connect with ReadyNas remote???. No - I've never had much success with that, works once and then never again.StephenB wrote: if you never get a functional frontview connection to the remote system [from any remote site], you could have a port forwarding problem on the US site's router. And you will also need to configure proper port forwarding for rsync (which router depends on where the backup job is being run).It starts to load the page but I get only the heading, border colours, & the top 3 buttons (refresh, etc.). I'm thinking it It wouldn't get that far if the ports weren't mapped properly, but having said that, I can see from the other forums, that many people have had that symptom when they have problems with frontview itselfStephenB wrote:Maybe you could try making some reasonable size files transfers (either with rsync or FTP), and post the measured transfer speeds and sizes?I'm not sure how to do that without being able to setup the remote NAS for ftp

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

22 Replies

Replies have been turned off for this discussion

StephenB
Guru - Experienced User
Dec 30, 2011
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...
Retired_Member
Dec 30, 2011
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.
StephenB
Guru - Experienced User
Dec 30, 2011
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:
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)...

Retired_Member

Dec 30, 2011

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/

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.

Jjnsgy

Aspirant

Dec 30, 2011

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

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?

StephenB
Guru - Experienced User
Dec 30, 2011
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).

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

StephenB

Guru - Experienced User

Dec 30, 2011

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.

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?

Retired_Member

Dec 30, 2011

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.

StephenB

Guru - Experienced User

Dec 30, 2011

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.

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.

Retired_Member

Dec 30, 2011

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.

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.

Forum Discussion

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

22 Replies

Related Content

No Access to Frontview

R7000P 5Ghz Unusable

MR80: Satellites become unusable after time while main router is fine?

render wlan unusable

cannot access frontview - ERR_SSL_VERSION_OR_CIPHER_MISMATCH

NETGEAR Academy

ProSupport for Business