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.

Reply to this note

Please Login to reply.

Discussion

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