Comcast and pfSense have intermittent problems reaching only Google
-
I've had a pfSense router controlling access to a DSL connection for a few years with everything working and now I'm switching to Comcast business cable. Both DSL and cable give me 5 static IPs which I use to host email/web/DNS for my personal domains. To make an orderly transition I added a NIC to the pfSense box and set up a multi-wan installation and overall it seems to be working with one fatal exception. As a test I've got one Win8 client laptop routed through the DSL and a different Win8 laptop routed through the Comcast connection. Speed test verifies that each laptop has the expected WAN IP address and speed.
The problem is that initially I can get to Google and Youtube just fine on the Comcast laptop, but after a few minutes I can no longer reach those websites. Other sites like CNN continue to work just fine. I can go to the command line and ping www.youtube.com just fine even though the browser can't get there. The DSL connected laptop sees no interruption. Android devices routed through the Comcast connection complain that they can't reach Google.
Both machines are using the same internal DNS server which is bind9 running on an Ubuntu machine and that DNS server does not use either ISPs DNS - it goes directly to the root DNS servers. That server is running with the -4 flag so it should only be returning IPv4 addresses.
On my Win8 client machine when I run ipconfig /all I see an IPv6 address starting with 2601 listed as the first DNS server and I don't know where that's coming from. My DHCP server isn't running on pfSense, but is also running on the same Ubuntu machine and IPV6 hasn't been configured.
I'm completely stumped. At first the only thing I could think of is that Google is trying to use an IPV6 address and IPV6 isn't set up properly on my network (I'm sure it isn't), but with IPV6 traffic disabled in pfSense and my DNS server only returning IPV4 addresses I don't see why that would be causing problems.
Even more puzzling is how it works initially and then stops working. It's not entirely clear what resets it back to working, rebooting the router seems to work for a while. I don't even know if this is actually DNS or IPV6 related, I just don't have any other ideas.
Can anyone tell me what I can try to troubleshoot this?
-
If you disable IPv6 on the 8.1 client does it stabilize? It does sound like something is returning v6 addresses.
I don't think the -4 flag does what you think it does. Specifying that, as I read the docs, only tells bind to use IPv4 for transport. It is perfectly legitimate to ask an IPv4 name server for AAAA records.
![Screen Shot 2014-12-24 at 2.05.14 PM.png](/public/imported_attachments/1/Screen Shot 2014-12-24 at 2.05.14 PM.png)
![Screen Shot 2014-12-24 at 2.05.14 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-12-24 at 2.05.14 PM.png_thumb) -
I did try disabling IPv6 on the Windows client at one point and I don't think that helped. I also didn't like that kind of fix because it would continue to be a problem for Android tablets and anytime a guest connected to the network.
Interesting point about the -4 option though. I saw it mentioned as a fix on a website, but that might not have been correct.
I even tried to go the other way and enable TCPv6 on pfSense, but I'm not sure what would need to change on my DHCP server and what settings I would have to get from the Comcast side. I want to learn how to set up TCPv6 at some point, but thought that didn't have to be this week's project and I could stay TCPv4 for now.
-
It's the fact that it initially works and then stops that's really got me nuts. Could this be some tables are getting filled up on the router or connections left unclosed? I'm looking for ideas of what to check to see what the cause might be.
-
I wasn't suggesting it as a solution, but as a troubleshooting step.
It's a problem because if your browser thinks it has IPv6 connectivity and asks for an AAAA record and receives one, it will try to connect to it.
Disabling IPv6 in 8.1 and rebooting should eliminate that as a possibility. That will enable you to perform troubleshooting steps without worrying about it. (traceroutes, pings, dns lookups, etc.)
-
I'll give it another shot. Thanks for working on this.
-
I turned off IPv6 on the Win 8.1 client and it seemed to work for 15-20 minutes then failed again. ipconfig /all shows no IPv6 settings for the wifi network connection on the client. I'm using the Firefox browser and turning on the Firebug debugger I'm showing a get on www.youtube.com as aborted with a remote IP of 173.194.121.5:80 after 37 seconds. But I can get to other sites just fine - CNN is loading normally.
So it doesn't look like an IPv6 problem after all (at least until I turn IPv6 back on in the client).
Any suggestions?
-
You need to move down a few layers and figure out what's really going on using the standard tools. Is it a DNS issue, can you ping, resolve names, traceroute, telnet to port 80, or what.
If it works then it doesn't we're going to need more to go on. Your browser is probably not going to give you the feedback you need to find out where the problem is.