Howdy, Stranger!

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


Shells Virtual Desktop
BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
Residential IPs in the US & 4G Mobile Proxies in EU & US with Unlimited Bandwidth
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
Shells Virtual Desktop
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.

Strange Firewall Behavior on New VPS? Can't SSH/Ping Depending on Source IP.

Hey everyone,

I'm running into a very strange issue with two new cheap VPS I bought for a year (one from Dedirock, one from vpshostingservice.co) and I'm hoping someone has seen this before.

My Goal:
I'm trying to set them up as nodes for my Remnawave / 3x-ui panel. My configuration is solid and works perfectly on all my other servers from different providers.

The Problem:
On these two new VPS, the node setup fails completely. At first, I thought it might be an IP ban (GFW-style in Myanmar), but the symptoms are too specific for that.

Here's the weird behavior I've diagnosed:

Pinging from my Home IP: Works fine.

Pinging from another one of my VPN servers: Fails. Connection times out.

The vpshostingservice.co server is even more confusing. The connectivity seems to flip depending on my source IP:

When my VPN is OFF (Connecting from my Home IP):

Ping: ✅ Works

SSH: ❌ Fails (Connection times out)

When my VPN is ON (Connecting from a VPN IP):

Ping: ❌ Fails

SSH: ✅ Works

What I've Checked:

It's not my configuration, as it works perfectly elsewhere.

I've checked the providers' control panels for any "Firewall Plans," and nothing is attached.

The server's internal firewall (iptables/ufw) is not the cause.

My best guess is there's a mandatory, provider-level firewall or "Security Group" that's not obvious in the control panel. It seems to have conflicting rules and is also blocking traffic from other data centers (which is why the node setup and pinging from another VPS fails).

Has anyone run into this kind of bizarre, stateful filtering with budget providers before? Any ideas on what this feature might be called in their panel or what I should specifically ask their support to disable?

Thanks in advance!

Comments

  • NVM , dedirock works after some times, vpshosting just sucks ip not clean :3

    Thanked by 1DediRock
  • DediRockDediRock Member, Patron Provider

    @moekyawaung said:
    NVM , dedirock works after some times, vpshosting just sucks ip not clean :3

    Well glad it all worked :)

    Need a different IP?

  • @DediRock said:

    @moekyawaung said:
    NVM , dedirock works after some times, vpshosting just sucks ip not clean :3

    Well glad it all worked :)

    Need a different IP?

    No it is working fine now but double bandwidth would rock !!
    Invoice #14196 XD

    Thanked by 1DediRock
  • DediRockDediRock Member, Patron Provider

    @moekyawaung said:

    @DediRock said:

    @moekyawaung said:
    NVM , dedirock works after some times, vpshosting just sucks ip not clean :3

    Well glad it all worked :)

    Need a different IP?

    No it is working fine now but double bandwidth would rock !!
    Invoice #14196 XD

    nice!

    awesome man done!! double bandwidth and added IPV6!!

    DediRock Hooks It Up™

    Thanked by 1stxsh
  • Rakane_SCRakane_SC Member, Host Rep

    This looks like upstream ACL filtering rather than anything on your instance. Some budget providers silently block traffic from known “datacenter” ASNs at the router level, it’s why home IPs work fine but VPN or other VPS networks can’t reach the port or even ping.

    You can confirm it with:

    mtr -rwzbc10

    Run it from both your home line and a VPN. If packets die 2–3 hops before the destination, the provider’s edge router or their DDoS appliance is dropping the flow.

    At ServerCrate (Path.net protected in Los Angeles), we handle mitigation at layer-4 so we don’t have to block whole ASNs. All clean traffic passes regardless of source.

  • @Rakane_SC said:
    This looks like upstream ACL filtering rather than anything on your instance. Some budget providers silently block traffic from known “datacenter” ASNs at the router level, it’s why home IPs work fine but VPN or other VPS networks can’t reach the port or even ping.

    You can confirm it with:

    mtr -rwzbc10

    Run it from both your home line and a VPN. If packets die 2–3 hops before the destination, the provider’s edge router or their DDoS appliance is dropping the flow.

    At ServerCrate (Path.net protected in Los Angeles), we handle mitigation at layer-4 so we don’t have to block whole ASNs. All clean traffic passes regardless of source.

    its been a while since ive seen anyone actively promote a service that uses path.net for their DDoS protection... since... well... https://lowendtalk.com/discussion/208614/path-net-over-1-million-in-debt-new-court-documents-reveal-the-details

    mind if I ask how is the protection suiting your needs?

  • Rakane_SCRakane_SC Member, Host Rep

    @LowEndStalker said:

    @Rakane_SC said:
    This looks like upstream ACL filtering rather than anything on your instance. Some budget providers silently block traffic from known “datacenter” ASNs at the router level, it’s why home IPs work fine but VPN or other VPS networks can’t reach the port or even ping.

    You can confirm it with:

    mtr -rwzbc10

    Run it from both your home line and a VPN. If packets die 2–3 hops before the destination, the provider’s edge router or their DDoS appliance is dropping the flow.

    At ServerCrate (Path.net protected in Los Angeles), we handle mitigation at layer-4 so we don’t have to block whole ASNs. All clean traffic passes regardless of source.

    its been a while since ive seen anyone actively promote a service that uses path.net for their DDoS protection... since... well... https://lowendtalk.com/discussion/208614/path-net-over-1-million-in-debt-new-court-documents-reveal-the-details

    mind if I ask how is the protection suiting your needs?

    Yeah, I’ve read the filings and that thread specifically prior to choosing Path. We’re not ignoring it, just separating drama from what actually impacts network performance.

    From our side, Path’s LA mitigation still runs clean. We colocate our own hardware in Los Angeles, so we’re directly connected into their award-winning backbone instead of running through resellers or remote tunnels. That gives us stable, low-latency throughput even under load, no upstream ACLs, no random filtering, no packet loss.

    We keep everything on monthly terms and have alternate transit ready if anything ever changes, but right now Path’s scrubbing and L4 protection are rock solid in LA.

    — Rakane, ServerCrate
    https://servercrate.net

    Thanked by 1LowEndStalker
  • My 2 cents on it would be to run a MTR from both of them see where the problem is. And post some screenshots here.

  • conceptconcept Member
    edited October 2025

    yea run some MTR tests and from my experience vpshostingservice.co network is just straight up awful. There are plenty of better providers on here.

Sign In or Register to comment.