All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Cloudzy VPS support refused root access, couldn't fix connectivity
Spectre_Whisper
Member
If you're eyeing a VPS from Cloudzy, here's some food for thought based on my recent experience. During the first week, connectivity on the assigned custom SSH ports was stable. On the 8th day, however, connections to any other non-standard SSH ports started timing out when accessed from outside the VPS.
Diagnostics I ran:
ss -tulpen confirmed that sshd was listening on both 2222 and 50022.
iptables -S | grep 2222 and grep 50022 confirmed ACCEPT rules in place.
tcpdump -i eth0 port 2222 showed incoming SYN packets reaching the VPS.
No corresponding replies left the VPS - despite sshd being active and reachable from localhost.
Same result from multiple networks: home ISP, mobile operator, VPN providers.
The host's support suggested needing root access to dig deeper, which felt like a sketchy ask for a hosting provider. They agreed the issue might not be on my end but wouldn’t budge on a refund since I was past their 7-day window.
Comments
Do the packets hit that rule? Are the counters updated? Are there any outgoing filters?
So it's almost certainly a firewall configuration issue on your side.
My checks went beyond just confirming ACCEPT rules:
ss hd was bound to 0 0 0 0 on both ports and reachable from local host (nc -vz 2 2 2 2 succeeded).
This looks like your doings. I don't like Cloudzy personally but here you are at fault. They couldn't fix it because you broke it.
Unless their service was marked as managed, they dont owe you anything other than keeping the service online, which in your case, it is.
This combination means the service itself was responding and local firewall rules were not blocking, but replies were dropped at a level outside my VPS.
Accusations like "you broke it" require proof. If someone claims the issue was caused by my configuration, they should point to concrete evidence - not just assumptions. And "unmanaged" doesn't mean the hoster is free of responsibility - it simply means they don't configure the OS for you. Ensuring that packets can flow to and from the VPS is their part of the deal. Saying "the service is online" is only formally true. A VPS that is powered on but whose network ports are unreachable from outside is effectively not usable.
Just ask them reinstall the VM and see if problem still persist
Do you see any reply being sent in tcpdump? If you don't see it in tcpdump, it's definitely your local issue.
Reinstalling a VM isn't a reasonable "fix" when the problem is clearly not caused by my configuration. Asking the client to wipe their server instead of providing proper diagnostics or guidance just shifts the blame.
If you claim it's my local issue, then show evidence. I've already explained that no reply packets were observed - and that's exactly why I contacted support in the first place. If the replies never leave the VPS, it can also mean that filtering occurs at the hypervisor or datacenter firewall level, which I cannot control or even check.
I understand it right that they offered you to dig into this and fix it for you, you declined because it feels "sketchy" and now you've created a LET account to complain that they didn't fixed your issue?
Sometimes I have the feeling people have too much time
I am assuming the answer to my question "Do you see any reply being sent in tcpdump?" is no - and that is your evidence that it is a local problem.
An outgoing packet shows up on your virtual network interface in your VPS before it reaches the hypervisor, so if you don't see it in your tcpdump, then there is definitely nothing going out.
You are assuming that if tcpdump doesn't show an outgoing packet, the problem must be inside my VPS. This assumption is flawed. Tcpdump only captures traffic visible at the virtual NIC. If the hypervisor or an upstream egress filter prevents replies from being generated or blocks them before they leave the VM boundary, I would not see them in tcpdump either.
Given that sshd is active, accepts connections locally on both ports, and iptables rules explicitly allow the traffic, the absence of replies in tcpdump does not automatically prove misconfiguration on my side. It only proves that packets don't exit the VPS - the root cause can still be on the hypervisor or provider's filtering layer.
Even if the issue originated on my side, it would not absolve the provider from offering guidance or support to resolve the configuration. A competent provider would recommend the necessary commands to resolve the issue instead of leaving the customer unsupported.
But they did offer to fix it
You're expecting tech support to teach you fundamental networking concepts and then walk you through step-by-step
This seems like an obvious issue on your end and I think it's generous that they offered to fix it. You didn't allow that
Your response focuses on emotion and assumptions rather than facts. Nowhere did I claim that tech support should guide me step-by-step. The so-called 'generosity' seems to mean expecting me to provide root access for routine verification - hardly an appropriate way to fulfill their responsibilities.
This entire thread is based on emotion and assumptions rather than facts
To say things like this and then call the provider incompetent is ironic. I would not give a provider root access, but I also would not break my network then demand that they fix it
You have an issue
You report it, they offer to look into it for you but any issues that are either going to or from your server will need to be checked from your server
How do you expect a provider to fix it if you do not allow them access to review what is actually going on?
Just seems pointless, they offer help, you refuse then throw your toys out the pram because they dare say no to a refund when you have not even allowed them a chance to fully review what is going on within your server.
This sounds like you call a mechanic because your car will not start but tell them, you cannot open the hood to look at the engine, you must stand at the bottom of the path and fix it
Reading this honestly makes me pause and thank god for the wonderful customers I get to work with.
If I was the host, I would refund just so I don't have to deal with this bs.
A provider can verify connectivity, open ports, firewall rules, and service status remotely by having the client run diagnostic commands, inspect accessible logs, perform packet captures from the client side, enable live monitoring of network traffic, or, if necessary, create a snapshot of the VM to analyze the configuration - all without requiring root access.
I posted on this forum to warn others about the issues they may encounter with this provider, not to vent emotions. Yet you continue defending the host based solely on assumptions rather than my actual experience, without providing a single factual argument. To summarize: I have never encountered such a poor policy elsewhere. No support team should ever demand a client's password. Customers should not be expected to understand how servers work, nor should they lose money because they don't. There are plenty of other providers to choose from.
How much are you paying here? If the server is a cheap unmanaged server they have already offered you help, if you want a provider to go to all this hassle start looking to pay high end prices. It sounds like you want a provider to jump every fence you set without question or real reason.
You are brand new here, maybe learn some providers here are well respected and go out of their way to help customers but some which appear to be like yourself attack providers because they wont give you every demand or you will cry like a child without sweets
You should be using shared hosting
Sounds like they're offering you free, managed support. Most people have to pay for that sort of thing.
If the egress packets don't even show up in tcpdump on your VPS, then something on your VPS has already blocked them. There's nothing the provider can do to magic your packets back at that point.
Given that you don't want to re-install the machine, have you tried removing ALL filtering rules and seeing if everything still works? If you won't even try that to rule out the possibility that you might have made a mistake, and you've turned down the provider's offer of help, there's probably not a lot anyone else can suggest to help you.
I noticed you use AI a lot, i'm 99.8% sure AI fucked up something in your config.
Delete or encrypt your private data and let them get access so they can fix your mistakes, or in the rare event it isnt your mistake they can find whats actually wrong.
Just for clarity, tcpdump shows all traffic at the vNIC irrespective of whether that packet later gets blocked by iptables, firewalld, etc.... Just because you saw the packet in tcpdump do not take that as proof the packet was seen by sshd.
Yes, they should, if they choose for unmanaged hosting. That's the name of the game, you're saving money on having it be unmanaged, as that's on you.
And no, using ChatGPT/Gemini/Claude/etc. to crap out config files doesn't count, at least not without at least some understanding of the config files themselves and knowing what it can and does get wrong.
As suggested above, shared hosting or managed hosting might be worth the extra cash, ditch the LLM subscription and I'm sure you can put it towards such hosting.
How much money have you lost?