Droid OS can't access websites, iPhones & Laptops can
-
Good morning,
I have an opt wifi interface that works perfect for laptops and iphones. I have Squid/Squidguard running on that interface to only block social networking/porn. I also have snort running on the WAN interface.
The problem is anyone running Android 4.x.x can't get to any websites. It may not be helpful, but when trying to access a website it displays the error "DNS_PROBE_POSSIBLE". I'm assuming that it's being blocked by Snort. I setup Snort using the first post in "Quick Snort Setup Instructions for New Users".
I cannot see any traffic under System > Firewall being blocked when trying to connect to websites. Using one the droid phones, I cannot ping outside by FQDN or IP address. I can't see the ping traffic either.
Any ideas? Thanks in advance!
-
I saw a bunch of http_inspect alerts in the snort logs so I added the suppression list by asterix seen here: http://forum.pfsense.org/index.php?topic=56267.0
I haven't seen a single http_inspect alert and after I restarted the snort interface Droid OS users still cannot access the internet. I also deleted Squid and Squidguard to narrow it down to Snort.
Anyone else experienced this issue?
-
Snort gives too much false positives. You will be better without it.
-
I saw a bunch of http_inspect alerts in the snort logs so I added the suppression list by asterix seen here: http://forum.pfsense.org/index.php?topic=56267.0
I haven't seen a single http_inspect alert and after I restarted the snort interface Droid OS users still cannot access the internet. I also deleted Squid and Squidguard to narrow it down to Snort.
Anyone else experienced this issue?
As a test, temporarily turn off Snort. You don't have to delete it, just click the green arrow icon on the WAN interface on the Snort INTERFACES tab. Once it turns to the red X, Snort will be stopped and not inspecting traffic. Next, go to the BLOCKED tab and clear any blocks by clicking the X to remove the blocked hosts. Now see if your Android stuff works. If so, you have found your suspect and can investigate further. If not, at least you will then have eliminated Squid, SquidGuard and Snort.
Bill
-
Snort gives too much false positives. You will be better without it.
With some knowledge and tuning, Snort can be a valuable tool in overall network security. It is sensitive, but proper setup and careful application of Suppress List entries keep you out of too many false positives.
Bill
-
Bill,
I disabled Snort and nothing was being blocked. I tried accessing a website by IP/FQDN and it still failed.
To test the access point, I hooked it up to one of the LAN ports and it worked. So something is blocking traffic on the OPT wifi interface. I don't understand why everything else works except for Droid devices including droid tablets. I attached a screenshot of the firewall rules.
I've also tried setting static IP/DNS on one of the droid devices and it still didn't work. I don't see anything in the firewall logs with the OPT Wifi interface or the IP I set statically. :o
Edit: Using a droid device, I cannot ping other devices on the wifi subnet and I cannot ping outside the subnet. While pinging and looking at the firewall logs, I see nothing from the IP of the droid, even though I have logging enabled on both the firewall rules. I can use other devices that can successfully connect to the internet to ping the droids.
-
Are you able to ping the gateway itself? Are the devices getting DHCP addresses? What happens when you traceroute to an external address? Do you have a different manufacturer's AP you could plug in to test? For my money, I'd say this most likely isn't a pfSense problem.
On an unrelated-to-the-problem note, "Droid" is a specific type of device. The OS itself is called "Android."
-
Tim,
I cannot ping the gateway. All devices are getting DHCP addresses. I've tried setting one up statically but that didn't fix the issue. Traceroute fails immediately. It's not the Access Point because if I plug it into the LAN and connect to it, it works fine.
I know the OS is android, I was just being lazy, sorry
-
Tim,
Here's the response when I try to ping the gateway:
–- IP (wlan0) fe80::867a:88ff:fe77:a362%wlan0
--- IP (wlan0) 10.0.1.105And that's it. No idea why it's showing IPv6 in the first line.
-
Tim,
Here's the response when I try to ping the gateway:
–- IP (wlan0) fe80::867a:88ff:fe77:a362%wlan0
--- IP (wlan0) 10.0.1.105And that's it. No idea why it's showing IPv6 in the first line.
I am still an IPv6 newb myself, but my suspicions are the IPv6 address being first is the problem. I believe that particular IPv6 address is the Link Local one. Perhaps the Android devices are trying to do everything with the IPv6 address? Do you actually run IPv6 on your networks?
Bill
-
Bill,
I do not run IPv6 on my networks. Even if I set IP settings to static, that IPv6 address still shows up when trying to ping/traceroute.
Edit: When I connect the same access point to the LAN interface, that IPv6 address still exists in "wlan0", but I can connect to the internet/ping/traceroute/etc. So, for some reason the OPT Wifi interface doesn't like this traffic. I can't even see traffic from the Android device being blocked or passed, even though I can see pfSense assign it an IP address under status > system logs > dhcp.
-
Where is your DHCP being provided from? Can you completely disable IPv6 on your access point?
-
DHCP is coming from pfsense. I cannot disable IPv6 on the access point as it doesn't handle dhcp requests, pfsense does.
-
Set your IPV6 configuration on that interface to "None." It doesn't make sense that this issue would only affect Android devices.
-
IPv6 config on that interface is already set to "none". I agree that it doesn't make sense, but for some reason it's only android devices. iOS and Laptops work perfectly fine.
-
Ok so it's fixed now. Here's the problem, and I have NO idea why this was a problem, in case someone runs into it in the future.
I had the Opt interface handling DHCP requests with the range 10.0.1.100 - 10.0.1.130. The IP of the interface was 10.0.1.0.
I decided, for the heck of it, to change the IP on the Opt interface to 192.168.0.1, and change the DHCP server range to 192.168.0.101 - 192.168.0.130. Now, all is working.
wtf??? :o :o >:( >:(
-
Ok so it's fixed now. Here's the problem, and I have NO idea why this was a problem, in case someone runs into it in the future.
I had the Opt interface handling DHCP requests with the range 10.0.1.100 - 10.0.1.130. The IP of the interface was 10.0.1.0.
I decided, for the heck of it, to change the IP on the Opt interface to 192.168.0.1, and change the DHCP server range to 192.168.0.101 - 192.168.0.130. Now, all is working.
wtf??? :o :o >:( >:(
10.0.1.0 would not be a normal interface IP. The ".0" value denotes the subnet or network itself. Devices (such as the firewall interface and other physical assets) generally start at ".1" and count up to one less than the broadcast address. Could be the Android devices consider this an invalid IP address and ignore it ??
Bill
-
You're right. I didn't even think about that since other devices were able to connect, that was dumb… Thanks for your help
