Periodic since 2.2 pages load blank, certs invalid
-
Running openssl from the firewall itself is a good idea, that'll at least bisect the issue. It seems unlikely it'd be on your ISP's side at least if it's the same ISP you're using to hit the forum, Comcast. It's possible, and given a change of WAN IP fixes it, that makes it seem more likely it's WAN-side, as nothing LAN-side would be impacted by that (unless it's just a coincidence). Some inept small ISP with a bunch of customers on the same broadcast domain and inadequate protection against things like ARP poisoning from customer to customer, I could see as being potentially more likely.
-
@cmb:
Running openssl from the firewall itself is a good idea, that'll at least bisect the issue. It seems unlikely it'd be on your ISP's side at least if it's the same ISP you're using to hit the forum, Comcast. It's possible, and given a change of WAN IP fixes it, that makes it seem more likely it's WAN-side, as nothing LAN-side would be impacted by that (unless it's just a coincidence). Some inept small ISP with a bunch of customers on the same broadcast domain and inadequate protection against things like ARP poisoning from customer to customer, I could see as being potentially more likely.
I should mention though, that when I release/renew the WAN interface, I'm not getting a new IP. I'm getting the same one. Breaking the connection seems to be what fixes it.
I can't speculate further until I can run the openssl command from pfsense when it happens again.And yes, currently Comcast, is the ISP in question.
I have one other theory as to the lolcat cert in that it's placeholder text in Firefox in the event that a cert loads completely blank, which would make sense as non SSL pages load blank while this is happening. I would need to look at (or ask someone familiar with) Firefox's sourcecode to know for sure.
But that will be answered when I run openssl from pfsense at least if I get something other than the cert I got when I ran it baseline for comparison.
-
I should mention though, that when I release/renew the WAN interface, I'm not getting a new IP. I'm getting the same one. Breaking the connection seems to be what fixes it.
…
And yes, currently Comcast, is the ISP in question.Comcast's DHCP leases are for a few days, which is why you don't get a new address with a release/renew. From looking at the DHCP client leases file on my box, it looks like they're about 4 days (renew time is half of the lease, and there's 2 days from renew to expire). IPv6 prefix leases are 7 days, from what I was told by a Comcast network engineer in another forum.
-
I know. I meant the issue wasn't stopping from my WAN IP changing when I release/renew.
-
We have had the exact same issue here in UK. We use BT as the ISP/
Same lolcat 3rd party self signed cert appearing for many sites, all DNS being redirected to 195.22.26.248 which shows as being a malicious IP in Portugal, used for lots of spammy domains.
Interestingly, we had Google DNS set on pfsense. When I changed this to OpenDNS the problem immediately went away, pings began to return correct IPs again etc.
I know Google DNS was hijacked before, so that is a possibility, but I would have thought an attack such as that would have hit the news on twitter by now.
-
We have had the exact same issue here in UK. We use BT as the ISP/
Same lolcat 3rd party self signed cert appearing for many sites, all DNS being redirected to 195.22.26.248 which shows as being a malicious IP in Portugal, used for lots of spammy domains.
Interestingly, we had Google DNS set on pfsense. When I changed this to OpenDNS the problem immediately went away, pings began to return correct IPs again etc.
I know Google DNS was hijacked before, so that is a possibility, but I would have thought an attack such as that would have hit the news on twitter by now.
Now THAT actually gives me something to go on.
My DNS servers are
4.2.2.2
8.8.8.8
4.2.2.1
8.8.4.4The 8.8.8.8 and 8.8.4.4 being Google DNS.
Are those the ones you have configured?EDIT: and that could also explain how releasing and renewing the WAN connection fixes it. If it loses connection with 4.2.2.2 and goes to Google's 8.8.8.8 and that's the problem, releasing/renewing might re-establish contact with 4.2.2.2.
-
We were using 8.8.8.8 and 8.8.4.4
Changed them over to opendns and machines responded almost immediately
-
We were using 8.8.8.8 and 8.8.4.4
Changed them over to opendns and machines responded almost immediately
That looks like it has a good chance at being the cause then.
I'm going to remove those from my list and just keep the Level3 ones (4.2.2.1 and 4.2.2.2) and see if it ever happens again.That might also explain why it didn't happen until right after the 2.2 upgrade if dnsmasq had a higher tolerance before falling over to the secondary DNS server than unbound does.
-
God, and I thought I was the only one having this problem since I came up reading this thread.
Any news about that? Same invalid cert, same google dns.
Spent the last night trying to figure out what the he** could have happened. -
God, and I thought I was the only one having this problem since I came up reading this thread.
Any news about that? Same invalid cert, same google dns.
Spent the last night trying to figure out what the he** could have happened.Other than us three, I haven't found anyone who reported it anywhere but here.
But it's way too coincidental that three people got the same symptoms and had the same dns.
-
Me also - Thats main reason I turned off forwarder and turned on unbound on one of my systems.
The kids were reporting same exact issues as you…Unbound with DNSSEC is technically slower than a forwarder but it seems faster in actual use and the kids report its solid.
I'm also using it over the VPN for my private use. -
NSA testing some new (broken) toys? :D
-
I will just say I like unbound and leave it at that… (-;
Unbound + VPN = my tinfoil hat
-
I just had this happen with level3 DNS (4.2.2.1 and 4.2.2.2) as the DNS servers. I removed them leaving ONLY OpenDNS and it immediately started resolving correctly again.
-
A lack of resolution could simply be a network error. I was really only seeing issue with HTTPS sites.
Cert errors just smell like MITM to me. -
A lack of resolution could simply be a network error. I was really only seeing issue with HTTPS sites.
Cert errors just smell like MITM to me.It's not a lack of resolution. It IS resolving to a different IP.
-
I'm certain no one would use DNS resolution to effect a MITM attack. (You are just paranoid)
-
I'm certain no one would use DNS resolution to effect a MITM attack.
That's actually pretty common, there's a variety of malware that will do just that to individual PCs, and sometimes to exploit routers and change their DNS servers so it impacts all LAN hosts. A variety of consumer-grade routers have been susceptible to such attacks.
-
I should mention though, that when I release/renew the WAN interface, I'm not getting a new IP. I'm getting the same one. Breaking the connection seems to be what fixes it.
After the further details later in the thread, I think why that has an impact is because it's triggering a DNS cache flush in the DNS forwarder, so the poisoned replies are no longer there.
-
haha - Yeah. I know. My sarcasm wasn't obvious enough? I'll try harder.
