Android saying "Connected, no Internet"



  • Just configured Pfsense firewall

    disabled the "allow all on LAN"

    only have the following ports allowed to go through from LAN to internet (any)

    DNS 53, NTP 123, HTTP/s 80/443, SMTPS 465, IMAPS 993
    &
    ICMP Echoreg for pings

    all else is blocked by default

    My access point is pointing to my server (DNS,NTP,DHCP) and gateway (pfsense box)

    However, Android is saying "Connected, no Internet". also happens on iphone
    Is there any other ports to make this work?

    "allow all on LAN" - makes this problem go away....



  • @Solway

    Why are you trying to block so much? If you must do that, fire up Packet Capture, to see what's happening.


  • LAYER 8 Moderator

    Or just have a look into the logs, find out your Android's IP and filter them and check, which ones got blocked.



  • im just locking down LAN so i know whats going outbound

    its quiet random ports from phone..

    like for example. ive just done a packet capture on my phone. turned off wifi, then back on.

    15:17:15.203757 IP 10.1.1.20.59988 > 172.217.169.68.443: tcp 0
    15:17:15.203799 IP 10.1.1.20.47438 > 172.217.169.67.80: tcp 0
    15:17:15.217647 IP 172.217.169.67.80 > 10.1.1.20.47438: tcp 0
    15:17:15.217661 IP 172.217.169.68.443 > 10.1.1.20.59988: tcp 0
    15:17:15.517409 IP 172.217.169.68.443 > 10.1.1.20.59988: tcp 0
    15:17:15.517425 IP 172.217.169.67.80 > 10.1.1.20.47438: tcp 0
    15:17:15.663620 IP 10.1.1.20.47438 > 172.217.169.67.80: tcp 0
    15:17:15.663643 IP 10.1.1.20.59988 > 172.217.169.68.443: tcp 0
    15:17:15.663667 IP 10.1.1.20.47438 > 172.217.169.67.80: tcp 232
    15:17:15.663807 IP 10.1.1.20.59988 > 172.217.169.68.443: tcp 517
    15:17:15.677669 IP 172.217.169.67.80 > 10.1.1.20.47438: tcp 0
    15:17:15.677685 IP 172.217.169.67.80 > 10.1.1.20.47438: tcp 83
    15:17:15.677874 IP 172.217.169.68.443 > 10.1.1.20.59988: tcp 0
    15:17:15.678140 IP 172.217.169.68.443 > 10.1.1.20.59988: tcp 154
    15:17:15.687442 IP 10.1.1.20.59988 > 172.217.169.68.443: tcp 0
    15:17:15.797630 IP 10.1.1.20.59988 > 172.217.169.68.443: tcp 0
    15:17:15.797690 IP 10.1.1.20.59988 > 172.217.169.68.443: tcp 43
    15:17:15.815192 IP 172.217.169.68.443 > 10.1.1.20.59988: tcp 0
    15:17:15.839442 IP 10.1.1.20.59988 > 172.217.169.68.443: tcp 238
    15:17:15.853425 IP 172.217.169.68.443 > 10.1.1.20.59988: tcp 0
    15:17:15.853943 IP 172.217.169.68.443 > 10.1.1.20.59988: tcp 152
    15:17:15.974323 IP 10.1.1.20.59988 > 172.217.169.68.443: tcp 0
    15:17:16.001484 IP 10.1.1.20.44128 > 1.0.0.1.853: tcp 0
    15:17:16.008681 IP 10.1.1.20.57883 > 1.1.1.1.853: tcp 0
    15:17:16.798402 IP 172.217.169.67.80 > 10.1.1.20.47438: tcp 83
    15:17:17.010786 IP 10.1.1.20.44128 > 1.0.0.1.853: tcp 0
    15:17:17.010802 IP 10.1.1.20.57883 > 1.1.1.1.853: tcp 0
    15:17:17.016479 IP 10.1.1.20.47438 > 172.217.169.67.80: tcp 0
    15:17:19.061397 IP 10.1.1.20.44128 > 1.0.0.1.853: tcp 0
    15:17:19.062291 IP 10.1.1.20.57883 > 1.1.1.1.853: tcp 0
    


  • @Solway said in Android saying "Connected, no Internet":

    its quiet random ports from phone..

    So, all you have to do is open all the random ports. 😉



  • haha, was hoping there was some information out there on ports that need to be open to check for internet connectivetity


  • LAYER 8

    if you can, put a screenshot of your lan rules, if you realy want only http/https traffic to go out from your lan you only need 53 / 80 / 443 as destination port (not source port)
    that's what i have on my guest wifi and iphone/android do not complain (later i have added port for whatsapp and playstore)



  • @Solway said in Android saying "Connected, no Internet":

    DNS 53, NTP 123, HTTP/s 80/443, SMTPS 465, IMAPS 993
    &
    ICMP Echoreg for pings
    all else is blocked by default

    When you nail down port access like that, you should be very precise.

    Suggestion : look at your firewall log file. You'll will find out fast enough the traffic that you blocked that should have been passed.

    Example : DNS port 53 - UDP ? TCP ? both ?
    etc ....

    edit : iPhone said Connected but not connected.
    That's ok : I'll put my bet on : "you broke DNS access".
    ( it should be destination port 53 - TCP and UDP - nothing else.)



  • fw rules.png image url)

    been testing with ports at bottom. but not working.


  • LAYER 8

    rules are processed from the top down, stopping at the first match, so i hope you don't have anything over "Allowed outgoing rules"



  • @kiokoman i have a block on one LAN ip, because its xp machine lol

    but yes allow is on that order. PCs work fine on ethernet.

    and also PCs work fine on WIFI

    its just android saying "connected, no internet" even if i open up the ports i see being logged.

    recon if theres anyhting in ICMP required?


  • LAYER 8

    what version of pfsense are you running?



  • @kiokoman
    2.4.4-RELEASE-p3 (amd64)
    built on Wed May 15 18:53:44 EDT 2019
    FreeBSD 11.2-RELEASE-p10

    i keep seeing random ports being blocked. when i open said ports and retry it cahnges to differenet ports



  • more info

    my wifi AP is a DD-wrt router in AP mode, connected to pfsense via network switch

    i have windows 2019, acting as AD, DNS, NTP, DHCP

    AP and pfsense is ported to win server for all the above.


  • LAYER 8

    android always try to go to different services (whatsapp / play store / google drive / huawai is probably stealing your data and sending it to china / samsung do the same but at least they tell you / etc etc )
    you should check if dns is working
    maybe try to disable ipv6 for the moment and see if it work via ipv4 only
    check day and time on your phone ..



  • I think you are confusion source port with destination port.
    Client's will almost always use a random source port to communicate with a well known destination port. Furthermore the firewall may reassign a random source port to the connection on the WAN side as well.
    For instance, in your packet capture list presented earlier, we can see host 10.1.1.20 source port 59988 communicating with a Google IP 172.216.169.68 on port 443.
    Return traffic is going to be implicitly allowed, this is the purpose of a stateful firewall. It knows and recognizes an allowed outbound connection and expects that return traffic is going to come back to the request and it will allow it, but only if there was an initial outbound connection. Basically, it doesn't just leave stuff open from outside unless you've initiated a connection.



  • @kiokoman
    ipv6 is disabled by default

    ive got custom rom,
    i see android is trying to get a google IP, then trys a DNS ip

    15:57:40.216282 IP 10.1.1.20.47570 > 172.217.169.67.80: tcp 0
    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.230392 IP 172.217.169.67.80 > 10.1.1.20.47570: tcp 0
    15:57:40.379510 IP 10.1.1.20.53298 > 216.58.206.100.443: tcp 0
    15:57:40.379569 IP 10.1.1.20.47570 > 172.217.169.67.80: tcp 0
    15:57:40.380885 IP 10.1.1.20.47570 > 172.217.169.67.80: tcp 232
    15:57:40.381306 IP 10.1.1.20.53298 > 216.58.206.100.443: tcp 180
    15:57:40.394470 IP 216.58.206.100.443 > 10.1.1.20.53298: tcp 0
    15:57:40.394901 IP 172.217.169.67.80 > 10.1.1.20.47570: tcp 0
    15:57:40.394910 IP 172.217.169.67.80 > 10.1.1.20.47570: tcp 83
    15:57:40.402846 IP 10.1.1.20.47570 > 172.217.169.67.80: tcp 0
    15:57:40.405092 IP 216.58.206.100.443 > 10.1.1.20.53298: tcp 1418
    15:57:40.405522 IP 216.58.206.100.443 > 10.1.1.20.53298: tcp 1133
    15:57:40.424643 IP 10.1.1.20.53298 > 216.58.206.100.443: tcp 0
    15:57:40.429217 IP 10.1.1.20.53298 > 216.58.206.100.443: tcp 0
    15:57:40.446462 IP 10.1.1.20.53298 > 216.58.206.100.443: tcp 85
    15:57:40.460026 IP 216.58.206.100.443 > 10.1.1.20.53298: tcp 276
    15:57:40.465991 IP 10.1.1.20.53298 > 216.58.206.100.443: tcp 238
    15:57:40.479929 IP 216.58.206.100.443 > 10.1.1.20.53298: tcp 152
    15:57:40.530769 IP 10.1.1.20.53298 > 216.58.206.100.443: tcp 0
    15:57:40.557255 IP 10.1.1.20.44262 > 1.0.0.1.853: tcp 0
    15:57:40.557306 IP 10.1.1.20.58017 > 1.1.1.1.853: tcp 0
    15:57:41.569937 IP 10.1.1.20.58017 > 1.1.1.1.853: tcp 0
    15:57:41.571296 IP 10.1.1.20.44262 > 1.0.0.1.853: tcp 0
    15:57:43.647856 IP 10.1.1.20.58017 > 1.1.1.1.853: tcp 0
    15:57:43.648647 IP 10.1.1.20.44262 > 1.0.0.1.853: tcp 0
    15:57:47.594139 IP 10.1.1.20.58017 > 1.1.1.1.853: tcp 0
    15:57:47.595599 IP 10.1.1.20.44262 > 1.0.0.1.853: tcp 0
    15:58:31.207046 IP 10.1.1.20.47575 > 172.217.169.67.80: tcp 0
    15:58:31.207078 IP 10.1.1.20.53303 > 216.58.206.100.443: tcp 0
    15:58:31.220075 IP 216.58.206.100.443 > 10.1.1.20.53303: tcp 0
    15:58:31.220821 IP 172.217.169.67.80 > 10.1.1.20.47575: tcp 0
    15:58:31.224669 IP 10.1.1.20.53303 > 216.58.206.100.443: tcp 0
    15:58:31.405049 IP 10.1.1.20.53303 > 216.58.206.100.443: tcp 517
    15:58:31.418632 IP 216.58.206.100.443 > 10.1.1.20.53303: tcp 0
    15:58:31.418643 IP 216.58.206.100.443 > 10.1.1.20.53303: tcp 154
    15:58:31.500980 IP 10.1.1.20.47575 > 172.217.169.67.80: tcp 0
    15:58:31.501001 IP 10.1.1.20.47575 > 172.217.169.67.80: tcp 232
    15:58:31.512938 IP 10.1.1.20.53303 > 216.58.206.100.443: tcp 0
    15:58:31.512958 IP 10.1.1.20.53303 > 216.58.206.100.443: tcp 43
    15:58:31.514883 IP 172.217.169.67.80 > 10.1.1.20.47575: tcp 0
    15:58:31.514914 IP 172.217.169.67.80 > 10.1.1.20.47575: tcp 83
    15:58:31.521415 IP 10.1.1.20.47575 > 172.217.169.67.80: tcp 0
    15:58:31.529562 IP 216.58.206.100.443 > 10.1.1.20.53303: tcp 0
    15:58:31.820584 IP 10.1.1.20.53303 > 216.58.206.100.443: tcp 238
    15:58:31.833817 IP 216.58.206.100.443 > 10.1.1.20.53303: tcp 0
    15:58:31.833848 IP 216.58.206.100.443 > 10.1.1.20.53303: tcp 152
    15:58:32.062625 IP 216.58.206.100.443 > 10.1.1.20.53303: tcp 152
    15:58:32.198460 IP 10.1.1.20.53303 > 216.58.206.100.443: tcp 0
    15:58:32.553957 IP 10.1.1.20.53303 > 216.58.206.100.443: tcp 0
    15:58:32.900797 IP 10.1.1.20.58020 > 1.1.1.1.853: tcp 0
    15:58:32.900812 IP 10.1.1.20.44267 > 1.0.0.1.853: tcp 0
    15:58:33.930800 IP 10.1.1.20.58020 > 1.1.1.1.853: tcp 0
    15:58:33.930813 IP 10.1.1.20.44267 > 1.0.0.1.853: tcp 0
    15:58:35.795403 IP 10.1.1.20.58020 > 1.1.1.1.853: tcp 0
    15:58:35.796295 IP 10.1.1.20.44267 > 1.0.0.1.853: tcp 0
    15:58:39.959164 IP 10.1.1.20.58020 > 1.1.1.1.853: tcp 0
    15:58:40.047545 IP 10.1.1.20.44267 > 1.0.0.1.853: tcp 0
    

  • LAYER 8 Moderator

    @Solway said in Android saying "Connected, no Internet":

    im just locking down LAN so i know whats going outbound

    its quiet random ports from phone..

    Not that random

    tcp/853 - DNS over TLS to cloudflares servers. Either configured on your phone or on autoselect and you use CF as DNS so they are probed.
    tcp/80, tcp/443 no problem

    also your "random ports" are exactly that but that is expected from answers to 80/443 traffic - after all that are answers to valid traffic. You should really check the System/Firewall Log for your phone and filter for your phone IP and check, what gets actually blocked instead of looking at a tcpdump with all data packets ;)

    @Solway said in Android saying "Connected, no Internet":

    been testing with ports at bottom. but not working.

    Explained above. They are NOT used. You read the dump wrong :) Check your TCP Flags. Everything other than "S" (Syn) isn't really relevant to your cause as it's data, resets, endings etc.



  • @JeGr
    you lost me there lol. as you might see im new to pfsense ☺

    i understand the stateful firewall thing... was hoping to allow known ports and not random stuff.



  • When you go for :

    @Solway said in Android saying "Connected, no Internet":

    disabled the "allow all on LAN"

    then you need to know for every application on your network ... :

    @kiokoman said in Android saying "Connected, no Internet":

    whatsapp / play store / google drive /

    what outgoing ports they are using. No exception.
    You'll be in for some Google time ^^



  • 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.
    convo.png


  • LAYER 8 Moderator

    @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.


Log in to reply