Maybe one of you hogs knows what’s up.
I got a new IP address for my VPS and updated the DNS A record accordingly. That was two days ago and I still get an “unable to connect” error when trying to access TankieTube through protonVPN.
However, if I drop the VPN everything works. This is the case with both Firefox and Chrome.
Does this have to do with DNS propagation?
It’s probably some automated block on the VPN provider’s part, but there is the ever so small chance that they have a misconfigured DNS server that ignored the TTL on the A record and is still trying to ping the old IP.
What reason would a VPN have to block websites? Usually it’s the websites blocking the VPNs.
It could be propagation, and it could also be the VPN itself being blacklisted - I don’t think it’s uncommon for commercial hosting services to blacklist VPN subnet blocks depending on the reputation of the VPN.
Could maybe try a traceroute from the VPS to your VPN IP
Traceroute can’t reach my VPN endpoint but neither can it reach my bare home IP because I’m behind a CGNAT.
I didn’t change hosting providers with my IP; they moved me to an IP block with a “cleaner” reputation at my request. Would the provider block a VPN from some of its subnets but not others?
It’s possible, it’s also possible that you got IP blocked temporarily for suspicious behavior but that would entirely depend on how your provider works
I just opened a ticket. We’ll see what they say.
Would it be unusual for a VPN provider to block access to subnets? That’s not how things work, right?
Yeah, I agree that it doesn’t seem very likely that the VPN is blocking any subnets
2 days says to me not DNS propagation
https://protonvpn.com/features/adblocker could be this or another one of Proton’s “protection” features (okay scare quotes is a little harsh but I kinda start to roll my eyes with that type of stuff)
I connect by OpenVPN instead of the app, so I don’t think I’m using that feature.
well you can rule out DNS issues by making sure it resolves properly using command line tools like dig. traceroute is hard to use on a lot of modern networks but a simple ping is still usable, or something like netcat or curl to rule out browser shenanigans
I have actually had some weird issues like this too, where I seemingly couldn’t reach hexbear from my former VPN provider at one point, but it eventually recovered, so maybe bad peering/blocking due to abuse going on from either the VPS provider or the VPN provider? But it was very annoying to troubleshoot and not that big of a deal so I don’t think I ever found a smoking gun
traceroute is hard to use on a lot of modern networks
Is that why most of the hops come back as
* * *?yeah
the internet was not designed for NAT, and it was not designed for ICMP to be disabled lol
I forget how to use it properly off the top of my head, but nslookup should be able to tell you what the dns lookup looks like and where the mismatch is coming from.
Is your VPN configured to use the domain name of your VPS or the IP?
I type the domain name into the browser and it uses protonVPN’s nameservers to get the IP afaik.
Ah okay so your VPS isn’t the VPN gateway, you’re using protonVPN’s. If you do a dig or nslookup against their DNS servers you cam confirm if their records are updated. If they are then I would guess like others in the thread suggested it’s something on Proton’s side
