passthrough.fw-notify.net

Hi BLS 

As I said in a similar thread, we have received several reports today of the same issue. We have escalated all the known cases so far and our team is investigating root cause. I will update your post once we know more.

Cheers,

Karlos

Is there any news on this being fixed soon Karlos? Seems there are alot of people having this issue

Hi James & Everyone,

The issue seems to be resolved. It could take up to 30 minutes to publish record.

It was fixed internally and was caused due to a DNS record being removed publicly which was required for browser authentication.

Please clear DNS caches and retest.

We've tested in our environment and can now resolve passthrough.fw-notify.net

Thanks,
Karlos

Thanks for the update - I can confirm that I can resolve passthrough.fw-notify.net to 213.144.15.19.

Is this FQDN always resolving to 213.144.15.19

Regards

Karlos,

Thank you for having support resolve the issue. passthrough.fw-notify.net now resolves to an IP, while before there was no DNS record for it. I believe only UTMs with transparent mode configured were affected. If you used standard/proxy mode, everything should have kept running. With that said, why is it that transparent mode broke? The UTM is supposed to intercept DNS requests for passthrough.fw-notify.net and redirect browsers to the firewall IP instead. From the looks of it, this is not what is happening. It feels like DNS requests to passthrough.fw-notify.net are still resolved and returned to client browsers. Only when traffic actually tries to go to the resolved IP, does the firewall translate it to the web filter interface. This works fine, but as we have all learned, it leaves a huge vulnerability/dependency on the passthrough.fw-notify.net DNS record for thousands and thousands of Sophos UTM installations worldwide. I guarantee you thousands of these installations are Enterprise and mission critical.

Now after that little rant, let's get to the real rant. How the %$#?!*&#%>! does a DNS record that is mission critical and that your entire UTM product line depends on get deleted. It's not like it's a complicated domain/zone with thousands of records. It is a dummy DNS domain. It only has ONE record! The passthrough.fw-notify.net A record!

Once you find out who decided to "play with DNS" today, please back slap them from all of us who were affected by this.

HZ

I have to agree with the above post. For something like this to happen and then get fixed without a clear reason as to what happened if this was one of my clients they would be going nuts for a RCA to be completed.

If I was to create a zone for the dummy DNS in our internal DNS servers and point it to the IP address above would that stop this from happening in the future?  And why does a dummy DNS even need to go to the outside world.

We were about 5 mins to a firmware rollback this morning because we couldn't make heads or tails as to what was going on and it wasn't until someone posted here and I sent a tweet to your support did we finally get an answer. It was sheer luck we are setup in a way that we could route production impacting internet traffic out another route so it wasn't using the UTMs this morning.

Hi JayMan!

JayMan said:

If I was to create a zone for the dummy DNS in our internal DNS servers and point it to the IP address above would that stop this from happening in the future?

You can use the Certificate for End-User Pages to specify the domain where the "passthrough" access will be looked in.

In this example, the UTM will redirect the users for authentications and download progress indicators to the hostname passthrough.mydomain.tld. And it will create automatically the entries in the UTM's local DNS cache system pointing this domain to 213.144.15.19.

If you use the UTM as the DNS server or as the forwarder for your internal DNS server, it's done. If you use your internal DNS server forwarding requests directly to the external world, you'll have to include the entry passthrough.mydomain.tld resolving to the above IP.

This option (which is located at Web Protection > Filtering Options > Misc) has the additional benefit of getting rid of the certificate error page on the fw-notify.net domain. If your company already have a *.mydomain.tld, you can upload it in the UTM and save your users for errors on auth pages (specially useful when using browser auth on guests network, for example).

Regards,

MM 

Thanks, Marcos - first time I knew this option was added!

As usual, the documentation probably was written by the developer instead of a documentalist.  Do I understand correctly that this is for the popup when an HTTPS access is blocked/warned for a device that does not have the UTMs HTTPS Proxy CA loaded?

Cheers - Bob

No, it's used for the authentication page when using the Browser auth method. It's also used for the redirect page that shows the download progress indicators.

The "access denied" message from the proxy during a HTTPS session still imposes the certificate problem for the users without the proxy CA. It "inserts" a content about blocked access into a page under the original domain, so it's impossible to provide a valid certificate. (btw, doing a redirect instead of showing the access denied is not possible either, since it happens after the initial TLS connection)

Regards,

MM

Could it be, that someone has forgotten to discheck the spf record, for the domain, when setting up the dns record again? We saw many mails not getting in with the standard from adress no-reply@fw-notify.net as per spf check at the mail gateway.

Kind regards

Achim

Could it be, that someone has forgotten to discheck the spf record, for the domain, when setting up the dns record again? We saw many mails not getting in with the standard from adress no-reply@fw-notify.net as per spf check at the mail gateway.

Kind regards

Achim