Howdy, Stranger!

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


Webhosting24 Sydney Launch: APAC Expansion #Continued - Page 2
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.

Webhosting24 Sydney Launch: APAC Expansion #Continued

2»

Comments

  • @jerry_me said:

    @dahartigan said:

    @jerry_me said:
    What do people usually buy servers in Australia for? It doesn't seem to be a good choice for the whole world except around Australia.

    LOL.. Personally, I buy servers in Australia because I live in Australia..

    This seems to be for the best, as I have tested that the speeds(latency) are not very good in many parts of the world, except around Australia.

    Los Angeles and Singapore are the 2 best options for Australia, unless you get something inside Australia, in which case Sydney is the best for international traffic in and out of your server. Perth if you want the best connection to Asian countries like Japan, Singapore, Hong Kong, etc

  • jerry_mejerry_me Member
    edited July 2021

    @yoursunny said:
    Webhosting24 is on the way to become the new premium provider.

    • routed /48 (every day)
    • Ryzen and NVMe (every day)
    • 7 worldwide locations (by end of 2021)
    • 10x10x10 (when the stars align)

    The routed prefix may require additional action.

    Thanked by 1tomazu
  • Since the megathread is closed I post here.
    I ordered LET 10x10x10 Los Angeles Edition.
    The initial deployment had some problem and I had to reinstall OS.

    I couldn't ssh to it, and through VNC I got:

    Maybe something you need to look into.
    After reinstalling it's working fine.

    Thanked by 1tomazu
  • tomazutomazu Member, Host Rep
    edited July 2021

    @Samidare said:
    Since the megathread is closed I post here.

    makes perfect sense ;-) Remember, our launch threads on LET are also our support threads. It does not matter if the launch was in Sydney or Los Angeles or the moon. We've doubled your bandwidth for v1815 😘

    I ordered LET 10x10x10 Los Angeles Edition.
    The initial deployment had some problem and I had to reinstall OS.
    Maybe something you need to look into.
    After reinstalling it's working fine.

    thank you for bringing this to my attention, will have somebody look into this ASAP. We normally have an extensive list of checks we perform on each location before going live, but we have been plagued by a LVM2-bug (regression: https://bugzilla.redhat.com/show_bug.cgi?id=1933640) and I guess this could be related to that bug, but has been fixed on that node in the meantime.

    Thanked by 1Samidare
  • SamidareSamidare Member
    edited July 2021

    Sorry, I didn't feel like opening a ticket for solved issue of flash sale.

  • tomazutomazu Member, Host Rep
    edited July 2021

    @Samidare said:
    Sorry, I didn't feel like to open a ticket for solved issue of flash sale.

    Great, I get it - it is much more fun to post here than to open a ticket using one of the many channels available or just writing a PM ;-) We all live in a meme world and love interaction, attention and fun and that is why your bandwidth was doubled (no joke).

  • Lol, you've really doubled the bandwidth :D
    I'm not sure if you are really angry or not for posting here since my English is not very good but sorry again.

  • yoursunnyyoursunny Member, IPv6 Advocate
    edited July 2021

    @yoursunny said:
    I just checked and found that my Munich 10-10-10 counted 500GB transfer this month, with 12~15GB inbound and 2~3GB outbound every day.
    There's no way my apps would generate this much traffic.

    I did 5 minutes of packet capturing, and noticed that the network has a lot of broadcast packets.
    In 334 seconds, I received 20290 broadcast packets under the following protocols:

    • Address Resolution Protocol (ARP) arp: 13537 packets
    • Cisco EIGRP eigrp: 218 packets
    • ICMPv6 Neighbor Solicitation icmpv6.type==135: 440 packets
    • ICMPv6 Multicast Listener Report Message v2 icmpv6.type==143: 317 packets
    • Internet Group Management Protocol (IGMPv3) igmp: 131 packets
    • Link-local Multicast Name Resolution (LLMNR) llmnr: 754 packets
    • Multicast Domain Name System (MDNS) mdns: 330 packets
    • NetBIOS Name Service (NBNS) nbns: 214 packets
    • Spanning Tree Protocol (STP) stp: 3691 packets
    • Virtual Router Redundancy Protocol (VRRP) vrrp: 658 packets

    Total packet length was 1414771 bytes.
    If the same broadcast traffic level continues at all times, it would consume 348MB inbound transfer per day.

    I don't know where the remaining 11GB inbound went, and I'll continue digging.
    No need to double anything, because 2TB is more than enough anyhow.


    If the person attacking me is reading, please kindly stop.

    If your IP is in the list below, please stop guessing my password.
    If I catch you again, I'll tell Santa Claus to put you on the naughty list.


    naughty list candidates
    Jul 02 18:32:36 vps9 sshd[104270]: Invalid user Redistoor from 104.248.49.90 port 59510
    Jul 02 18:32:37 vps9 sshd[104272]: Invalid user admin from 187.38.63.71 port 27025
    Jul 02 18:36:06 vps9 sshd[104326]: Invalid user default from 187.38.63.71 port 26717
    Jul 02 18:39:33 vps9 sshd[104430]: Invalid user MikroTik from 187.38.63.71 port 26882
    Jul 02 18:42:56 vps9 sshd[104473]: Invalid user profile1 from 187.38.63.71 port 21335
    Jul 02 18:46:35 vps9 sshd[104571]: Invalid user user1 from 187.38.63.71 port 27036
    Jul 02 18:49:47 vps9 sshd[104619]: Invalid user admin1 from 187.38.63.71 port 21140
    Jul 02 18:56:25 vps9 sshd[104714]: Invalid user ubnt from 187.38.63.71 port 26762
    Jul 02 18:59:35 vps9 sshd[104756]: Invalid user administrator from 187.38.63.71 port 21052
    Jul 02 19:02:45 vps9 sshd[104799]: Invalid user web from 187.38.63.71 port 26909
    Jul 02 19:05:32 vps9 sshd[104849]: Invalid user user from 187.38.63.71 port 27015
    Jul 02 19:08:37 vps9 sshd[104890]: Invalid user support from 187.38.63.71 port 26781
    Jul 02 19:11:51 vps9 sshd[104992]: Invalid user tech from 187.38.63.71 port 21095
    Jul 02 19:14:47 vps9 sshd[105033]: Invalid user demo from 187.38.63.71 port 26763
    Jul 02 19:17:28 vps9 sshd[105076]: Invalid user oracle from 49.232.9.144 port 48180
    Jul 02 19:17:31 vps9 sshd[105078]: Invalid user demo from 187.38.63.71 port 21468
    Jul 02 19:17:39 vps9 sshd[105080]: Invalid user telecomadmin from 187.38.63.71 port 26815
    Jul 02 19:19:02 vps9 sshd[105103]: Invalid user finance from 101.34.4.117 port 36492
    Jul 02 19:19:07 vps9 sshd[105105]: Invalid user telecomadmin from 187.38.63.71 port 21415
    Jul 02 19:22:50 vps9 sshd[105140]: Invalid user tc from 45.240.88.147 port 42146
    Jul 02 21:26:03 vps9 sshd[105959]: Invalid user postgres from 209.141.59.244 port 37354
    Jul 02 21:26:03 vps9 sshd[105961]: Invalid user user from 209.141.59.244 port 37356
    Jul 02 21:26:03 vps9 sshd[105957]: Invalid user test from 209.141.59.244 port 37348
    Jul 02 21:26:03 vps9 sshd[105960]: Invalid user vagrant from 209.141.59.244 port 37352
    Jul 02 21:26:03 vps9 sshd[105962]: Invalid user ubuntu from 209.141.59.244 port 37346
    Jul 02 21:38:37 vps9 sshd[106022]: Invalid user pi from 93.136.94.80 port 35554
    

    Thanked by 1Gravely
  • codydobycodydoby Member
    edited July 2021

    Dear boss,
    One of my SGP-EGG-2021 looks like this now:

    It seems that the 22 port is blocked?

  • yoursunnyyoursunny Member, IPv6 Advocate

    @codydoby said:
    It seems that the 22 port is blocked?

    I tested with ping.sx and it shows worse:

    TCP traceroute to port 22 is reachable, but there's packet loss: (this is from Oracle Cloud Tokyo)

    $ sudo traceroute -T -p 22 84.33.16.112
    traceroute to 84.33.16.112 (84.33.16.112), 30 hops max, 60 byte packets
     1  140.91.206.30 (140.91.206.30)  0.189 ms 140.91.206.50 (140.91.206.50)  0.157 ms 140.91.206.31 (140.91.206.31)  0.142 ms
     2  61.200.80.62 (61.200.80.62)  0.893 ms  1.496 ms  1.087 ms
     3  61.200.80.61 (61.200.80.61)  1.739 ms  1.965 ms  1.671 ms
     4  ae-4.r31.tokyjp05.jp.bb.gin.ntt.net (129.250.3.57)  1.169 ms  1.681 ms  1.449 ms
     5  ae-2.r30.tokyjp05.jp.bb.gin.ntt.net (129.250.5.23)  2.047 ms  1.392 ms  1.665 ms
     6  ae-2.r26.tkokhk01.hk.bb.gin.ntt.net (129.250.2.51)  51.096 ms ae-1.r01.sngpsi07.sg.bb.gin.ntt.net (129.250.4.94)  67.651 ms  70.539 ms
     7  ae-0.r27.tkokhk01.hk.bb.gin.ntt.net (129.250.5.29)  47.943 ms 116.51.27.122 (116.51.27.122)  69.474 ms ae-0.r27.tkokhk01.hk.bb.gin.ntt.net (129.250.5.29)  45.906 ms
     8  ae-7.r22.sngpsi07.sg.bb.gin.ntt.net (129.250.7.66)  76.909 ms  82.842 ms *
     9  ae-2.r23.sngpsi07.sg.bb.gin.ntt.net (129.250.4.74)  76.112 ms * *
    10  84.33.16.112 (84.33.16.112)  69.063 ms  69.143 ms *
    

    Are you sure it's not your firewall having some kind of rate limiting?

    Thanked by 1dahartigan
  • codydobycodydoby Member
    edited July 2021

    @yoursunny said:

    @codydoby said:
    It seems that the 22 port is blocked?

    I tested with ping.sx and it shows worse:

    TCP traceroute to port 22 is reachable, but there's packet loss: (this is from Oracle Cloud Tokyo)

    $ sudo traceroute -T -p 22 84.33.16.112
    traceroute to 84.33.16.112 (84.33.16.112), 30 hops max, 60 byte packets
     1  140.91.206.30 (140.91.206.30)  0.189 ms 140.91.206.50 (140.91.206.50)  0.157 ms 140.91.206.31 (140.91.206.31)  0.142 ms
     2  61.200.80.62 (61.200.80.62)  0.893 ms  1.496 ms  1.087 ms
     3  61.200.80.61 (61.200.80.61)  1.739 ms  1.965 ms  1.671 ms
     4  ae-4.r31.tokyjp05.jp.bb.gin.ntt.net (129.250.3.57)  1.169 ms  1.681 ms  1.449 ms
     5  ae-2.r30.tokyjp05.jp.bb.gin.ntt.net (129.250.5.23)  2.047 ms  1.392 ms  1.665 ms
     6  ae-2.r26.tkokhk01.hk.bb.gin.ntt.net (129.250.2.51)  51.096 ms ae-1.r01.sngpsi07.sg.bb.gin.ntt.net (129.250.4.94)  67.651 ms  70.539 ms
     7  ae-0.r27.tkokhk01.hk.bb.gin.ntt.net (129.250.5.29)  47.943 ms 116.51.27.122 (116.51.27.122)  69.474 ms ae-0.r27.tkokhk01.hk.bb.gin.ntt.net (129.250.5.29)  45.906 ms
     8  ae-7.r22.sngpsi07.sg.bb.gin.ntt.net (129.250.7.66)  76.909 ms  82.842 ms *
     9  ae-2.r23.sngpsi07.sg.bb.gin.ntt.net (129.250.4.74)  76.112 ms * *
    10  84.33.16.112 (84.33.16.112)  69.063 ms  69.143 ms *
    

    Are you sure it's not your firewall having some kind of rate limiting?

    My god I have not blurred the IP totally.
    I have no idea about that. I have not logged in for more than 1 month. Anyone in the same situation as me?

    PS. I canoot reboot the server now
    https://www.webhosting24.com/cp/clientarea.php?action=productdetails&id=ID&modop=custom&a=reboot

  • @codydoby said:
    My god I have not blurred the IP totally.

    LOL

  • yoursunnyyoursunny Member, IPv6 Advocate
    edited July 2021

    @codydoby said:

    @yoursunny said:
    Are you sure it's not your firewall having some kind of rate limiting?

    My god I have not blurred the IP totally.

    Server IP is public information.
    If you blur the IP, forum members wouldn't be able to help you.

    I have no idea about that. I have not logged in for more than 1 month. Anyone in the same situation as me?

    You can scan the /24 and find other servers with open port 22, then use the same online tool to find out whether there's also significant loss on their port 22.

    If you have other open TCP ports, do they have high packet loss also?
    Loss limited to only one port is likely a server problem, such as an overloaded SSH daemon.


    WHMCS-Virtualizor integration has always been slow.
    "Loading Panel options" embedded in WHMCS more than a minute.

    Since yesterday, Virtualizor two-factor email is not being delivered to Gmail, so that login has to go through the "↗️ Enduser Panel" button in WHMCS.
    I'm also getting 524 errors on WHMCS occasionally.

    For information: I'm connected to Cloudflare Ashburn; my VPS is in Munich.

  • JioJio Member

    @yoursunny said: Since yesterday, Virtualizor two-factor email is not being delivered to Gmail, so that login has to go through the "↗️ Enduser Panel" button in WHMCS.

    Why does this feel like vulnerability to me? If you can set up 2FA in Virt but no 2FA in WHMCS, and lets you bypass 2FA?

  • yoursunnyyoursunny Member, IPv6 Advocate

    @Jio said:

    @yoursunny said: Since yesterday, Virtualizor two-factor email is not being delivered to Gmail, so that login has to go through the "↗️ Enduser Panel" button in WHMCS.

    Why does this feel like vulnerability to me? If you can set up 2FA in Virt but no 2FA in WHMCS, and lets you bypass 2FA?

    I don't want 2FA.
    Webhosting24 Virtualizor would turn on 2FA automatically, but email delivery isn't working.

  • tomazutomazu Member, Host Rep
    edited July 2021

    @Jio said:

    @yoursunny said: Since yesterday, Virtualizor two-factor email is not being delivered to Gmail, so that login has to go through the "↗️ Enduser Panel" button in WHMCS.

    Why does this feel like vulnerability to me? If you can set up 2FA in Virt but no 2FA in WHMCS, and lets you bypass 2FA?

    you can enable 2FA for your Webhosting24 control panel account (so no double 2FA).

  • tomazutomazu Member, Host Rep
    edited July 2021

    @codydoby said:
    It seems that the 22 port is blocked?

    it is not, this must be something on your server - either your own firewall/rate-limiter or your SSH port getting hammered.

    We reserve the right to block port 25 if certain red flags appear, but that is only to prevent SPAM and is not related to port 22/SSH.

    @codydoby said:
    PS. I canoot reboot the server now

    sometimes operations take a little bit longer and CF times out after 60 seconds. The underlying server and service keeps working nonetheless.

  • DPDP Administrator, The Domain Guy

    @yoursunny said: Virtualizor two-factor email is not being delivered to Gmail

    Oh, it's working for me though.

    Thanked by 1tomazu
  • yoursunnyyoursunny Member, IPv6 Advocate

    @tomazu said:
    sometimes operations take a little bit longer and CF times out after 60 seconds. The underlying server and service keeps working nonetheless.

    This is not an excuse of having non-functional user experience.
    You need to either disable Cloudflare proxy or reprogram the WHMCS-Virtualizor integration so that it doesn't rely on slow HTTP requests (WebSockets and polling are two options).

  • @yoursunny said:

    @codydoby said:

    @yoursunny said:
    Are you sure it's not your firewall having some kind of rate limiting?

    My god I have not blurred the IP totally.

    Server IP is public information.
    If you blur the IP, forum members wouldn't be able to help you.

    I have no idea about that. I have not logged in for more than 1 month. Anyone in the same situation as me?

    You can scan the /24 and find other servers with open port 22, then use the same online tool to find out whether there's also significant loss on their port 22.

    If you have other open TCP ports, do they have high packet loss also?
    Loss limited to only one port is likely a server problem, such as an overloaded SSH daemon.


    WHMCS-Virtualizor integration has always been slow.
    "Loading Panel options" embedded in WHMCS more than a minute.

    Since yesterday, Virtualizor two-factor email is not being delivered to Gmail, so that login has to go through the "↗️ Enduser Panel" button in WHMCS.
    I'm also getting 524 errors on WHMCS occasionally.

    For information: I'm connected to Cloudflare Ashburn; my VPS is in Munich.

    Thank you for your reply, I have learned it.

  • tomazutomazu Member, Host Rep
    edited July 2021

    @yoursunny said:

    @tomazu said:
    sometimes operations take a little bit longer and CF times out after 60 seconds. The underlying server and service keeps working nonetheless.

    This is not an excuse of having non-functional user experience.
    You need to either disable Cloudflare proxy or reprogram the WHMCS-Virtualizor integration so that it doesn't rely on slow HTTP requests (WebSockets and polling are two options).

    I will look into this, but before reprogramming the entire integration we would switch to CloudStack or OpenStack like we use for Server24 and adjust pricing accordingly. This being said, I am pretty sure this is only a temporary glitch and have escalated the issue with Virtualizor support also so that their tech-support will look into this.

    And while I agree with you that this is not an excuse, I do not agree that it is a non-functional user experience (at least by your own writing that sometimes operations take a little bit longer and CF times out), but worth optimizing for sure.

    @codydoby said:
    Thank you for your reply, I have learned it.

    so this is now solved and was an issue specifically with your configuration?

  • tomazutomazu Member, Host Rep
    edited July 2021

    @yoursunny said:
    Since yesterday, Virtualizor two-factor email is not being delivered to Gmail, so that login has to go through the "↗️ Enduser Panel" button in WHMCS.
    I'm also getting 524 errors on WHMCS occasionally.

    @yoursunny the deliverability issue to GMail should have been solved now and the timeouts should no longer appear, but I am waiting for final confirmation about that.

    So I hope that @yoursunny today #yourfunny ;-)

    But please keep the feedback coming and thank you @FAT32 for cleaning up.

    Thanked by 2yoursunny FAT32
  • yoursunnyyoursunny Member, IPv6 Advocate
    edited July 2021

    @tomazu said:

    @yoursunny said:
    Since yesterday, Virtualizor two-factor email is not being delivered to Gmail, so that login has to go through the "↗️ Enduser Panel" button in WHMCS.
    I'm also getting 524 errors on WHMCS occasionally.

    @yoursunny the deliverability issue to GMail should have been solved now and the timeouts should no longer appear, but I am waiting for final confirmation about that.

    2FA emails are coming, but they are landing in Spam folder now …
    Reason given is "similar messages are identified as spam".
    I'm clicking "report not spam" button.

    Virtualizor is still much slower than April:

    • Duration since submitting username + password until 2FA screen appearing: 23 seconds
    • Duration since clicking ➡️ button on "virtual servers" page until "VPS information" page appears (showing OS, locations, etc; not counting the time loading Overview tab): 35 seconds

    (in Virtualizor itself, not through WHMCS)

    So I hope that @yoursunny today #yourfunny ;-)

    You aren't the first one calling me that, and won't be the last.

    I am a Builder, so You can be a Hoster.

  • tomazutomazu Member, Host Rep

    @yoursunny said:
    2FA emails are coming, but they are landing in Spam folder now …

    OK, this should settle soon, just a short warmup period (at least I hope).

    Virtualizor is still much slower than April:

    • Duration since submitting username + password until 2FA screen appearing: 23 seconds
    • Duration since clicking ➡️ button on "virtual servers" page until "VPS information" page appears (showing OS, locations, etc; not counting the time loading Overview tab): 35 seconds

    so, this is inside Virtualizor now, not in WHMCS, right?

    So I hope that @yoursunny today #yourfunny ;-)

    You aren't the first one calling me that, and won't be the last.
    I am a Builder, so You can be a Hoster.

    yeah, got that one and so true!

  • Kyle_Kyle_ Member

    You say “XGB premium bandwidth”

    Is there an option for unmetered “normal bandwidth”?

  • tomazutomazu Member, Host Rep

    @Kyle_ said:
    You say “XGB premium bandwidth”

    Is there an option for unmetered “normal bandwidth”?

    no, we generally try to use premium carriers and upstreams.

Sign In or Register to comment.