New Static IP address seems to be blocked and PlusNet Helpdesk are unable to help!

[#1]

That's good.

Underneath, In the services box, click on Common Ports.

[#2]

Using my mobile phone (not connected to WIFI), I get the same result when trying the Static IP as my colleague gets from his own home computer!

Thsi site can;t be reached. xxx.xxx.xx.xx took too long to respond. Try: Checking the connection. ERR_CONNECTION_TIMED_OUT.

[#3]

Can't see a Services box !

[#4]

Sure you're using the correct IP address ?

https://www.whatsmyip.org/ 

[#5]

Yep!. IP Address matches what's shown in my router, my Plusnet account and what I get back from whatsmyip.

[#6]

[#7]

[#8]

Looking at the tracert in your first post, is this from a device on your network as it goes through 15 hops, it should only show 1 hop as the start and end hops are the same. Reckon you need help from a Plusnet expert to look into it.  Hopefully someone will pick this up or one of the Mods could apply a little pressure……

[#9]

The tracert was actually done by a friend from his own machine to test the connection!

Oh well. Thanks very much for trying. 

[#10]

Did you check the security settings on the Synology box ?

[#11]

I honestly don't think it's getting as far as the NAS!

[#12]

On the account page temporarily untick the ‘enable auto block’ as you may be blocking everybody.

On the same page are there any entries in the allow/block list ?

[#13]

I'm almost certain this is a local configuration problem i.e. an issue with the NAS or something (virtual or otherwise) sat in between it and the router.

The port forwarding configuration looks fine (assuming the device selected in the drop-down is indeed the NAS).

The Hub One will not respond to PING/ICMP traffic on the WAN interface, so traceroutes/pings timing out is a red herring and entirely expected. The traffic is reaching the hop before your network so it looks to be getting to you.

ShieldsUp/Canyouseeme etc. will only report success if the device on your network is both reachable *and* listening/responding to traffic on the relevant port/interface (which it needs to be). If the latter is not the case, then the port forward is irrelevant. It can be set up correctly and you'll still see failure when running these tests.

Also, a static IP is not a requisite for remote access. If you're unable to remotely access your server when assigned a dynamic IP either, then this is further evidence that the static IP is not the source of the problem. 

Like @Dan_the_Van - I have hosted webservers behind port 80 when using a Hub One in the past with no problems whatsoever.

Checking the Event Log under the Helpdesk section of the Hub Manager is a good suggestion.

@Champnet wrote:

I've worked with several routers that just won't allow connection to the external side from the local network.

Not an issue with the Hub One as it supports NAT loopback.

[#14]

@bobpullen  Thanks for clearing up a few points, didn't think the Shields Up port scanner relied on ICMP requests.

[#15]

@Champnet - it doesn't. It does require that the machine on the local network is actively listening to/responding to probes on a given port though.