I just discovered a fascinating thing.
I've been struggling to solve an internet problem at my parents home for several days, a router and some other stuff cannot connect to internet; the strange part is that my PC and my phone work. My first thought was related to the fact that I use a VPN, but this doesn't make much sense, since VPNs usually are the problem, as they add one more hop to the connection chain.
I did a lot of tests and at the end, exhausted, I decided to order a new cheap router to see if this was the culprit. Today I installed it, same exact problem, damn.
So I noticed that the modem has a diagnostic area with the usual ping and traceroute tools, and I tried them: "unknown host".
This is really crazy, all the WAN/LAN are down, the modem itself cannot see the internet, but with my PC I can connect around and shitpost on Nostr?
So I contacted my ISP and discovered that they suddenly, and without any alert (bastards), disabled the line because there was an unpaid invoice from months ago for an unknown reason, and they are not smart enough to use the credit card they already have to automatically pay it.
Here comes the most interesting part: how does a VPN bypass the administrative suspension on a line and give me free internet?
Did I exploit a huge hole in my ISP (and who knows how many others) infrastructure?
Can any networking guru explain this?
Replies (26)
Congrats on their free internet! π
It depends how the ISP "disabled" the line.
Maybe they just blocked access to their DNS (or even to any other DNS), and having the VPN connection you could connect with no problems to other DNS and then to wherever else in the internet because other ports were not blocked?
Can you do some nmap scan to detect which communication is blocked?
ISPs love to block traffic based on remote ports. Do they also have a cable or telephone subscription on the same service and just had an internet bill that was overdue? If so, they may have wanted to keep traffic open for cable or phone services while best effort blocking common traffic like http and stuff?
"unknown host" is usually a dns resolution failure, where you simply having DNS resolution failures?
this, it prob means dns was turned off, and your devices had it cached.
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.
Yeah caught that unknown host part right before I smacked the sign button, agreed.
Both the PC and the phone were connect to wifi, no phone data.
At the beginning of my tests I also tried to change the DNS, and then pinging directly a remote IP; the issue is not related to the domains resolution.
How can I use nmap to find something useful here?
It's not a DNS block, since I tried to change them and also ping directly some IPs.
Pinging a IP from the modem gives "Request timed out".
I'm connected via WireGuard; maybe they are blocking TCP connections, or selected ports.
daniele
At the beginning of my tests I also tried to change the DNS, and then pinging directly a remote IP; the issue is not related to the domains resolution.
How can I use nmap to find something useful here?
View quoted note →
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?).
daniele
At the beginning of my tests I also tried to change the DNS, and then pinging directly a remote IP; the issue is not related to the domains resolution.
How can I use nmap to find something useful here?
View quoted note →
I use Android.
Hmm, In that case if you have the motivation, id try some port knocking and see what happens. Otherwise yeah, could be TCP specifically, although I can't see a case where they would want to block blanket L4 traffic like that.
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.
By no means am I any expert, but I found that you can try scanning with:
$ sudo nmap -sS -Pn -T5 -p- [target- ip]
Your PC was using your phone.
TCP/IP hurts
The name of ISP?? πππ
The main Italian ISP π
E quale VPN usi? Intendo il servizio da chi offerto? PerchΓ© da quanto ho capito la vpn Γ¨ wireguard.
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.
Brave Search
Wireguard udp
WireGuard uses UDP as its transport protocol, which is essential for its performance and design [2]. It operates over UDP to avoid the performance ...
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.
daniele
Follow-up: after some tests I discovered that the ISP is blocking the TCP layer, but UDP is allowed (e.g. dig and nslookup work). So my WireGuard connection can easily pass through.
Now I'm really curious to know how many of you are going to don't pay the next invoice to test this possibility π
View quoted note β
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
