Windows PCs cannot connect to google sites
-
I have a Netgate SG-2220. A contractor upgraded to version 2.4.4-RELEASE-p2 last week without telling me. I don't know what the previous version was, but I suspect it was 2.3.something.
Since the update, the two Windows PCs on the LAN (Windows 7 and Windows 10) cannot connect to any Google sites. For example, connecting to gmail eventually times out with "This site can't be reached. accounts.google.com took too long to respond". The problem happens with all browsers and also affects docs and drive. If they try to load the main google search site, the search field shows up but the rest of the page doesn't load.
The PCs can load other sites such as Amazon or Microsoft. The PC can also connect to gmail from other networks (e.g., by tethering to a cell phone's data plan). One PC is wired and one is using wifi. We've tried loading in safe mode and have also scanned both PCs for viruses with AVG and also with the Windows tools.
All of the Macs on the LAN are unaffected.
Suggestions gratefully accepted.
-
Are you using any packages like squid, snort, suricata or pfBlocker? Are you using IPv6?
-
@KOM the only installed packages are aws-wizard, ipsec-profile-wizard and sudo.
According to the contractor, IPv6 was enabled on the WAN using DHCP6 but he turned it off because due to a bug that prevented an upgrade with DHCP6 turned on. I've since turned it back on, but our ISP is not serving IPv6 addresses anyway, so I don't think that it makes a difference.
IPv6 is not enabled on the LAN interface.
-
Pfsense doesn't care nor can it tell what OS some client devices is running...
Your saying the PC can access all other sites but can not access accounts.google.com?
Does this site resolve for the client, do a nslookup on the box... What comes back.
-
@johnpoz it seems that all google sites eventually need to talk to accounts.google.com for authentication. Thus docs, mail, drive, etc. also need to fetch data from accounts.google.com and that fetch times out. www.google.com can display the basic information (e.g., search bar) but still wants to fetch data from accounts.google.com to add user-specific context to the page; that part times out.
Nslookup seems fine; it returns 172.217.3.205.
I've done quite a bit of DNS troubleshooting - verified that there isn't a bogus hosts file on the PC and switched between a few different DNS providers (google, opendns, cloudflare). None of that made a difference.
I am aware that pfsense is OS agnostic. Nonetheless, the only devices affected are running Windows. MacOS and iOS are not having this problem.
-
Well I suggest you sniff and see what the issue is then when your client tries to make the connection.. All pfsense does is push packets, and then nat them to your public IP..
Without some other packages install it doesn't give 2 shits where the packet is going, nor does it know that source OS is linux or windows, etc.
Sniff and go from box that works, and then windows machine and see what is different.
Software on the machine - like some anyvirus would be one possible problem.
-
After some more sleuthing, it turns out that the Windows systems were getting the wrong netmask (/8 instead of /22). I'm unsure why this is, because the firewall's LAN address and the DHCP server are both configured with the correct netmask, and other systems such as Macs are getting the correct netmask.
Only Google's services were noticeably affected because their addresses seem to be mostly on the 172. network, and our LAN is using the 172.16. private IP range.
Hard-coding the Windows' addresses and netmask solved the problem, but I have no idea why they are getting the incorrect netmask from DHCP.
Viewing a packet capture in Wireshark shows that the PC does a DHCP discover, and the firewall is sending an offer, so I don't think that it's a rogue DHCP server on the network. I don't know enough about analyzing packet dumps to know if anything is out of the ordinary but I can make the dump available if anybody is interested.
-
Replying to myself... scrolling down to the very bottom of the DHCP config page to Additional BOOTP/DHCP Options shows that there was an option 1 of type Text with a blank value. Option 1 is - tada - subnet mask.
So my operating theory is that macOS defaults to a different netmask than Windows, so getting a bogus or missing option 1 only caused problems for Windows and not the other OSes.
I've removed that extra option from the pfsense config but won't be able to test my hypothesis until my next on-site, which won't be until next week.
-
post up your pcap of the dhcp conversation, discover, offer, request and ack.
If your saying the dhcpd is sending out the correct mask, and others are using it correctly - then you got something wacked on those clients!
Options shows that there was an option 1 of type Text with a blank value. Option 1 is - tada - subnet mask.
So yeah that would F it up big time!! But you would of seen that in the offer, or lack of the offer containing mask.
