Filter Check Fails at One Building

[mdburr]

We've been dinged in an audit because http://filter.lds.org check fails. Looking at the router on http://tm.lds.org, it shows green. Going to the building and connecting to the network, I can see I'm getting the right DNS entries (8.35.35.92, 8.34.34.92), yet the check fails. This building is unusual in that we use a 4G connection and CradlePoint for the Internet access. I took the 4G dongle and checked that it is also configured to use one of the Church DNS servers.

Also, as a test, while on that network, I set my computer to use the Church DNS servers, and then used Wireshark to watch the traffic while I did a DNS lookup for http://filter.lds.org; I can see my system connect to 8.35.35.92 for the DNS lookup, but the response it gets back is filterfail.cloudapp.net.

Any thoughts what's going on here?

[peon]

I'll ask the simple question. First I'd check to make sure the computer is connected/behind the churches router. It shouldn't matter what type of internet connection you have. Next I'd check to see if the IP address and DNS server are set to obtain automatically.

[russellhltn]

This building is unusual in that we use a 4G connection and CradlePoint for the Internet access.

Check to see that the only thing connected to it is the church firewall. And if the computer in question is using WiFi, make sure it's connecting to the church network and not the 4G modem.

If your local network checks out, call Global Support. It could be that TM is giving a false indication and that the script isn't running correctly.

You might also try a website like gambling.com. If you can get though to that, the filter is not working.

[Biggles]

I randomly check to see if the filter is working. On occasion it fails. I've checked the status in TM, which has stated everything is operating correctly. Doing absolutely nothing to the system, a few days later I've found the filter is fine again.

My thoughts on this issue are: -

1. Probably server issues, especially on a Sunday, that used to be a regular occurrence in the early days of the filter implementation.

2. Some kind of maintenance on the firewall, or at the server end, on other days of the week.

Either way the issue resolved itself without intervention, on my part!

If you still have the issue when trying the filter at other random times, then I'm guessing you have a more serious problem.

[dpenrod75]

I had a similar issue in one our buildings. Called SLC and the guy at the time said the filtering itself was intermittent and their engineers were looking into a fix. That was months ago though. Our problem cleared up when I upgraded the firewall, so I have no clue what the underlying issue really was.

[SterlingMcClung]

I have seen some ISPs that will silently redirect DNS requests to their own DNS servers. This is unusual, but it does happen. It is done at the IP level, so even though you specifically try to connect to one DNS server(even using tools like nslookup or dig), the packets are redirected to a different server. If this is the case, then you should be able to get your ISP to change this, but you might have to talk to 2nd or 3rth level support; the first level guys may not even know what you are talking about.

[SterlingMcClung]

Russsel,

While I understand your reason for the suggestion, I am pretty sure the documentation specifically says not to try to access inappropriate sites in order to test the filter. Doing this from a clerk computer could result in an infected computer.

[Biggles]

gambling.com at one time was the recommended site to test the effectiveness of the filter. I'm not sure if that is still a recommendation. I'm not in a position at the moment to check if that still stands!

[russellhltn]

gambling.com at one time was the recommended site to test the effectiveness of the filter. I'm not sure if that is still a recommendation.

I'm not finding anything to indicate that's it's still current. You do want to be careful. At one time such sites were target for malware, but the operators have figured out it's bad for business, so at least the major ones have good security to assure repeat customers.

[tlhackett]

This building is unusual in that we use a 4G connection and CradlePoint for the Internet access.

There lies the problem. Most mobile carriers have their own DNS servers programmed into their wireless card. When the firewall sends the DNS lookup through to the wireless card, the card in turn makes its own request to its DNS server and returns that response back to the firewall mimicking as if it came from 8.35.35.92 or 8.34.34.92. This is called DNS hijacking. Changing the settings on the wireless card to our DNS servers will solve this. Contact your ISP to get support on doing this.