Android saying "Connected, no Internet"
-
I've found that using Wireshark to capture or read in a tcpdump file and using the Statistics -> Conversations feature to be particularly helpful.
It will display who is talking to whom and on what port.
For instance below we can see many connections going to Address B and port B, this is what you're interested in. In this case all port 443. Be sure to also look at the UDP tab to see what UDP traffic is going out. Google also uses QUIC which is a stateless HTTPS over UDP port 443.
-
@Solway said in Android saying "Connected, no Internet":
i understand the stateful firewall thing... was hoping to allow known ports and not random stuff.
No problem :) Point is, you were reading your capture "wrong" or better "not completely". As you perhaps know, stateful filters filter the traffic by matching the first packet (a SYN packet) against your filter table and allow or block it, then create a state and match traffic to that state so it doesn't have to repeat the lookup process for every single packet of e.g. a download but the first.
So you had this part in your capture:
15:57:40.216322 IP 10.1.1.20.53298 > 216.58.206.100.443: tcp 0 15:57:40.229403 IP 216.58.206.100.443 > 10.1.1.20.53298: tcp 0 15:57:40.379510 IP 10.1.1.20.53298 > 216.58.206.100.443: tcp 0
and read it like "I must open port 53298". But look what has happened: your client (IP .20) requested a HTTPS connection (port 443 on the remote IP xyz.100) and got an answer from it (2nd line) and afterwards sent data to it (3rd line). So your port 53298 is just that: a random high port a client has to use as per protocol when connecting to a remote server speaking HTTPS. That is specified as "client with random high port >1023 [source] to server port 443 [destination]". All other traffic belonging to this connection is passed through the stateful filter. So no need for opening random ports as it isn't the problem you are looking for.
That's why I was telling you, you should instead have a look in "System Logs / Firewall" as there passes or blocks are only listed when matching the filter so no unnecessary packets (like in a tcpdump) are on display. So I'd enable logging on all block/pass rules on your interface the smartphone is connected, disable its WiFi, re-enable it and then check and filter the logs for your android's IP so you only get it to display packets coming from your smartphone and them being passed or blocked. If you see blocked entries, check where they are going and on what port. I assume there are some checking IPs to see if the device has internet connectivity similar to those IPs/Domains/URLs they check to discover if you are behind a portal so they can display their notification that you need to do some portal login.