Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Hosthatch http and https not work?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Hosthatch http and https not work?

TeoMTeoM Member

Hello Guys,

I have somehow since a few days problems on my VPS at Hosthatch in Amsterdam Netherlands from the blackfriday action on http or Https URLs to access.

It does not affect all URLs but only a few e.g. : wieistmeineip.de or Speedtest.net or iplocation.net

Can someone check if he also has the problem ?

E.g. when I do wget speedtest.net it should download a HTML page but it waits all the time for the https request. With other server providers it works. I use Firefox on my server and it loads and loads but nothing comes only a timeout.

«1

Comments

  • webcraftwebcraft Member
    edited April 2021

    Maybe reinstall? This sounds like a software problem not an issue particularly of your unmanaged hosthatch vps.

  • PilzbaumPilzbaum Member
    edited April 2021

    Could you share logs of your commands maybe? Without any information what is going wrong it's hard to tell..
    And please use verbose logging!

  • TeoMTeoM Member

    @webcraft said:
    Maybe reinstall? This sounds like a software problem not an issue particularly of your unmanaged hosthatch vps.

    No it isn't an software problem. Because wget is not an external software. Yes firefox of course but the problem appear since a few days I think

  • brueggusbrueggus Member, IPv6 Advocate

    I just tried wget speedtest.net and can confirm that it runs into a timeout on my Hosthatch AMS VPS. A traceroute towards speedtest.net looks fine though, so I suspect that they're throttling/blocking certain IPs/Networks on their end.

  • TeoMTeoM Member

    wget -v speedtest.net
    --2021-04-20 11:59:42-- http://speedtest.net/
    Resolving speedtest.net (speedtest.net)... 151.101.130.219, 151.101.66.219, 151.101.194.219, ...
    Connecting to speedtest.net (speedtest.net)|151.101.130.219|:80... connected.
    HTTP request sent, awaiting response... 301 Moved Permanently
    Location: https://www.speedtest.net/ [following]
    --2021-04-20 11:59:42-- https://www.speedtest.net/
    Resolving www.speedtest.net (www.speedtest.net)... 151.101.130.219, 151.101.66.219, 151.101.2.219, ...
    Connecting to www.speedtest.net (www.speedtest.net)|151.101.130.219|:443... connected.

  • TeoMTeoM Member

    @brueggus thank you very much for conformation. I wait and wait but connecting timeout

  • TeoMTeoM Member

    Before the Downtime yesterday everythink works. I think

  • TeoMTeoM Member

    @brueggus No it is on the site of hosthatch because I have as well an VPN to my server and there speedtest.net works.

  • dosaidosai Member

    @TeoM said:
    wget -v speedtest.net
    --2021-04-20 11:59:42-- http://speedtest.net/
    Resolving speedtest.net (speedtest.net)... 151.101.130.219, 151.101.66.219, 151.101.194.219, ...
    Connecting to speedtest.net (speedtest.net)|151.101.130.219|:80... connected.
    HTTP request sent, awaiting response... 301 Moved Permanently
    Location: https://www.speedtest.net/ [following]
    --2021-04-20 11:59:42-- https://www.speedtest.net/
    Resolving www.speedtest.net (www.speedtest.net)... 151.101.130.219, 151.101.66.219, 151.101.2.219, ...
    Connecting to www.speedtest.net (www.speedtest.net)|151.101.130.219|:443... connected.

    Same error on my storage VM. However, nvme loads fine

  • TeoMTeoM Member

    @dosai I think it must be an firewall Issue on hosthatch server. That port 80 and 443 are blocked somehow.

    But the strange think is why I can access to speedtest.net with mv phone over vpn to hosthatch ? Or with my notebook over vpn to hosthatch.

  • My guess is the MTU is too big due to some jumbo frames thing on the new router. Try reduce the MTU, e.g. ip link set dev eth0 mtu 1400, to see if it works.

    Thanked by 2Razza skorous
  • # ping google.com -f -c 1 -s 1472
    PING google.com (172.217.16.142) 1472(1500) bytes of data.
    
    --- google.com ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 7ms
    rtt min/avg/max/mdev = 7.560/7.560/7.560/0.000 ms
    # ping google.com -f -c 1 -s 1473
    PING google.com (172.217.16.142) 1473(1501) bytes of data.
    .
    --- google.com ping statistics ---
    1 packets transmitted, 0 received, 100% packet loss, time 10000ms
    
  • TeoMTeoM Member

    @tetech said:

    # ping google.com -f -c 1 -s 1472
    PING google.com (172.217.16.142) 1472(1500) bytes of data.
    
    --- google.com ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 7ms
    rtt min/avg/max/mdev = 7.560/7.560/7.560/0.000 ms
    # ping google.com -f -c 1 -s 1473
    PING google.com (172.217.16.142) 1473(1501) bytes of data.
    .
    --- google.com ping statistics ---
    1 packets transmitted, 0 received, 100% packet loss, time 10000ms
    

    Can you explain that ?

  • Read previous message

  • RazzaRazza Member

    On my AMS vps ever since last night they moved to a new rack had network issue, I think @tetech is correct with the mtu causing it, I changed the default mtu 1500 to 1450 all the network issue I noticed like random timeouts disappeared.

  • yoursunnyyoursunny Member, IPv6 Advocate

    We need a no MTU=9000 hall of shame.
    @HostHatch will not be on this list, but one of their upstream providers will be.

    I want the entire Internet to support jumbo frames!


    When you run TCP, the TCP sender should have Path MTU Discovery.
    Your interface MTU could be set to a high value, but PMTU discovery is supposed to find out the proper packet size over the path, and then align TCP segment size accordingly.

    If PMTU discovery isn't working properly, you should check your firewall to see if ICMP "fragmentation needed" messages are allowed.
    This message type is needed for PMTU discovery to work.

    As usually, tcpdump and Wireshark are your friends.
    wget and ping logs are of limited usefulness.

    Thanked by 2Daniel15 bulbasaur
  • @Hosthatch @Emil can you give any info about whether the changes in AMS would affect PMTU or discovery? Thanks.

  • I confirm the problem. Can't run bench.monster on AMS storage VPS anymore

  • hosthatchhosthatch Patron Provider, Top Host, Veteran

    We're making some changes in Amsterdam (we sent out the maintenance emails about this to everyone affected).

    This should be fixed shortly.

  • I confirm I received one email per VPS, so the downtime should not be much of a surprise. Still down, though.

  • Amsterdam seems to be moved to a new upstream. Traffic to my home ISP is routed through Germany now :(. NFOrce had direct peering.

    Host Loss%   Snt   Last   Avg  Best  Wrst StDev
     1. 31.187.64.10.0%    16   19.0  21.5  12.5  29.6   4.9
     2. 225.56.237.178.hosted-by.hostcircle.com0.0%    16    0.3   4.4   0.2  65.2  16.2
     3. ae1-1965.cr4-ams2.ip4.gtt.net0.0%    16   14.9  16.6  14.7  34.7   5.3
     4. ae32.cr1-fra6.ip4.gtt.net0.0%    16   11.4   7.8   6.6  13.1   2.1
     5. ffm-s1-rou-1102.DE.as286.net0.0%    16    6.7   6.7   6.6   6.8   0.0
     6. rt2-rou-1022.NL.as286.net0.0%    16   15.5  15.8  15.5  17.1   0.5
     7. nl-rt2-pice-ir01.kpn.net86.7%    16   10.1  10.1  10.0  10.1   0.1
     8. ???
     9. 8x.xx.xx.xxx0.0%    15   12.1  11.9  11.8  12.1   0.1
    

    Thoughts @hosthatch ? Routing optimalisation in the making?

  • hosthatchhosthatch Patron Provider, Top Host, Veteran
    edited April 2021

    Please open a ticket in that case :)

    The issue in question here (in the OP) was fixed a few hours ago.

  • Maybe they are busy with preparing more storage offers as promised last week.

  • @hosthatch said:
    Please open a ticket in that case :)

    Will do, but had to check here first.

  • @debaser said:
    Amsterdam seems to be moved to a new upstream. Traffic to my home ISP is routed through Germany now :(. NFOrce had direct peering.

    Host Loss%   Snt   Last   Avg  Best  Wrst StDev
     1. 31.187.64.10.0%    16   19.0  21.5  12.5  29.6   4.9
     2. 225.56.237.178.hosted-by.hostcircle.com0.0%    16    0.3   4.4   0.2  65.2  16.2
     3. ae1-1965.cr4-ams2.ip4.gtt.net0.0%    16   14.9  16.6  14.7  34.7   5.3
     4. ae32.cr1-fra6.ip4.gtt.net0.0%    16   11.4   7.8   6.6  13.1   2.1
     5. ffm-s1-rou-1102.DE.as286.net0.0%    16    6.7   6.7   6.6   6.8   0.0
     6. rt2-rou-1022.NL.as286.net0.0%    16   15.5  15.8  15.5  17.1   0.5
     7. nl-rt2-pice-ir01.kpn.net86.7%    16   10.1  10.1  10.0  10.1   0.1
     8. ???
     9. 8x.xx.xx.xxx0.0%    15   12.1  11.9  11.8  12.1   0.1
    

    Thoughts @hosthatch ? Routing optimalisation in the making?

    Sounds like bandwidth costing a fortune and they needed to block speedtests until on the new provider?

  • hosthatchhosthatch Patron Provider, Top Host, Veteran
    edited April 2021

    @TimboJones said:

    Sounds like bandwidth costing a fortune and they needed to block speedtests until on the new provider?

    No, we never 'blocked' anything in particular.

    Thanked by 2hanoi TimboJones
  • hosthatchhosthatch Patron Provider, Top Host, Veteran

    @debaser said:

    @hosthatch said:
    Please open a ticket in that case :)

    Will do, but had to check here first.

    We are waiting for Core-backbone to accept some of our prefixes - but not sure what range you are on and whether that has anything to do with this. We can look into it once you have a ticket in and get you a resolution :)

  • brueggusbrueggus Member, IPv6 Advocate

    @TimboJones said:

    Sounds like bandwidth costing a fortune and they needed to block speedtests until on the new provider?

  • @hosthatch said:

    @debaser said:

    @hosthatch said:
    Please open a ticket in that case :)

    Will do, but had to check here first.

    We are waiting for Core-backbone to accept some of our prefixes - but not sure what range you are on and whether that has anything to do with this. We can look into it once you have a ticket in and get you a resolution :)

    Mentioned that in my ticket too. Ingress goes through Core Backbone and stays in NL.

    Thanked by 1hosthatch
  • @hosthatch said: The issue in question here (in the OP) was fixed a few hours ago.

    Yes, the MTU thing does seem to be fixed - no need to manually lower MTU now.

    Thanked by 2hosthatch dosai
Sign In or Register to comment.