this, it prob means dns was turned off, and your devices had it cached.
Discussion
the VPN had an IP address so it didn't need that, and then the devices were going through the VPN to get DNS. this is normal with stuff like wireguard, usually you set one or two DNS IP addresses to use with it and they get elevated to higher priority (lower metric) than the rest of the connections and it goes through the VPN for it.
pretty funny that the ISP was blocking their access just by blocking DNS tho. but that above is the reason why the VPNed devices were getting through, everything until a non-firewalled outbound was going via IPs.
It's not a DNS issue since:
And pinging an IP from the modem gives a "timeout" error.
More probably they are blocking all the TCP connections, and WireGuard works over UPD (right?).
port 53 was being blocked. the port being used by the VPN was not, and once it was in the VPN it was outside the firewall.
No:
> And pinging an IP from the modem gives a "timeout" error.
ICMP goes on a port also that they probably block
next
actually, i lied. ICMP messages can be dropped by one of the next hops in the path.
you'd have to tracepath/traceroute to find out how far into their network you can get
also they may have allowed UDP in general, or at least not blocked it on whatever paths or ports.
there are tools to explore all of this if you are curious.
you didn't say what kind of VPN you were using also. some use UDP. that's why i suggested that also.
i get why you are interested though. this ISP's security guys are obviously lazy or stupid.
From the modem I can also fire a traceroute, it immediately returns a timeout.
Instead dig works.
I told that in a previous repky, the VPN uses WireGuard.
It seems to me a classic Occam's razor situation.
that was just a guess it was wireguard. https://search.brave.com/search?q=wireguard+udp&source=desktop&conversation=6aea02d872b7fd5286fdd0&summary=1
it is possible that they were not blocking UDP and it generally uses random high ports.
wireguard is awesome btw. i use it all the time.
btw, HTTP/3 also uses UDP, but not many servers support it yet. not sure how good browser support is either. but it's awesome, like, so nostr uses http/1 or http/2 websockets, the equivalent with http/3/QUIC is "WebTransport" which is far better - not only is it over UDP, the sockets multiplex so where previously clients might open 5 separate websocket connections, each of them taking like 200ms of upgrade negotiation, with WebTransport it's one connection and i could be misremembering but the upgrade is not a round trip, you just fire off the open and then follow straight up with your requests and each goes on a separate part of the multiplexed connection.
probably is a couple years more before WebTransport and HTTP/3 are in common use but obviously this ISP will have to update their network security
Yeah caught that unknown host part right before I smacked the sign button, agreed.