Squiz websites blocked by firewall?

(Murray Gregory) #1

Hi Guys

 

Not sure if this is directly related to Squiz but I thought I would ask.

A website is being blocked on our company network. I checked the source code of the website (using a mobile data connection) and it looks like it was made using Squiz Matrix.  The website is http://tac.vic.gov.au. In Chrome the error coming up is 'no data received'. There is no record in the logs of our Fortigate firewall saying it has been blocked. We have added an exception to allow it through the firewall but it is still not working.  The strange thing is I get the same error visiting http://squiz.net and http://squizsuite.net (although I can access http://forums.squizsuite.net/ ok).

 

All of these website work fine outside our network which is behind a Fortigate firewall.

 

As I mentioned, i'm not convinced Squiz is the issue but it does seem like a coincidence.

 

Any help would be appreciated,

 

(Jacob Gardiner) #2

 

 

All of these website work fine outside our network which is behind a Fortigate firewall.

 

As I mentioned, i'm not convinced Squiz is the issue but it does seem like a coincidence.

 

Any help would be appreciated,

 

 

I've seen some odd behaviour like this in the past, when there's an intermediary proxy (like the Fortigate) in between Matrix and the browser. It could be a number of different things that might be causing it, but i'm hesitant in pointing a finger without getting a little more info. 

 

If you have linux/osx/something that can run curl - can you try do the following for each site and throw the results in pastebin or PM them to me?

curl -I -v http://www.tac.vic.gov.au/
curl -I -v http://www.squiz.net/au

You should see some results like:

 

$ curl -I -v http://www.tac.vic.gov.au/
* Adding handle: conn: 0x7fa120803a00
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fa120803a00) send_pipe: 1, recv_pipe: 0
* About to connect() to www.tac.vic.gov.au port 80 (#0)
*   Trying 103.1.193.73...
* Connected to www.tac.vic.gov.au (103.1.193.73) port 80 (#0)
> HEAD / HTTP/1.1
> User-Agent: curl/7.30.0
> Host: www.tac.vic.gov.au
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
HTTP/1.0 200 OK
< Server: ngx_openresty
Server: ngx_openresty
< Date: Fri, 19 Sep 2014 04:27:13 GMT
Date: Fri, 19 Sep 2014 04:27:13 GMT
< Content-Type: text/html; charset=utf-8
Content-Type: text/html; charset=utf-8
< Vary: Accept-Encoding

Also, If you're a customer and need some priority attention, i'd recommend going through the support team. 

(Murray Gregory) #3

 

If you have linux/osx/something that can run curl - can you try do the following for each site and throw the results in pastebin or PM them to me?

Also, If you're a customer and need some priority attention, i'd recommend going through the support team. 

 

Hi Jacob. Thanks for getting back to me. Here are the results from Curl (basically is it 'Empty response from server')

 
http://pastebin.com/h352yrmX
Cheers
Murray
(Jacob Gardiner) #4

 

Hi Jacob. Thanks for getting back to me. Here are the results from Curl (basically is it 'Empty response from server')

 
Murray

 

 

Thanks for sending those details through. 

 

I've taken a look through logs on our end, and (un)surprisingly there's nothing coming from the IP you provided me in PM since the 19th of Sept. Although, you clearly did make some requests via curl after then.

 

So, here's what I'm thinking at the moment..

 

The Fortigate appliance on your network is performing some caching to save bandwidth internally however it may be either specifically ignoring the HTTP headers that are provided to it, on request of the client, or it might not be liking the headers we are sending it. 

 

Ignoring the TAC site for now, because that sends cache headers which complicates things a little further.. On the Squiz website, we provide a HTTP header which tells any intermediary devices, in this case the Fortitude appliance, to specifically not perform any caching and to forward all requests to us. It does this using the following headers, which are visible using curl -I (that's capital i):

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0, no-cache="set-cookie"
Pragma: no-cache

What can happen is one of two things: The fortitude is configured to ignore/manipulate these headers which is breaking the website for end users, or it may not be compatible with Pragma or Cache-Control headers (this is why we send both, so that older devices that use Pragma headers can still comply with our caching instructions).  

 

Anyway, I don't think this is good news, because you need to go back to your network team that manages the appliance and ask them to drop the cache & please review any header manipulation. 

 

The good news is, that both of those websites use TLS/SSL - which creates a secure connection between you and the website, so that a corporate proxy won't be able to modify the connection. If you try both websites with https:// instead of http://  - they should hopefully work. 

(Murray Gregory) #5

Hi Jacob,

 

Thanks for the very detailed answer. I will pass that on to our firewall people. I tested out the https:// and that does seem to work fine. I had actually tried it before but I had not added the www. I realise now it  only works with www.

I really appreciate all of your help. Hopefully we can make some firewall changes to allow the non secure version through as we will probably have users with this issue again.

Cheers!

Murray

(Jacob Gardiner) #6

Hi Jacob,

 

Thanks for the very detailed answer. I will pass that on to our firewall people. I tested out the https:// and that does seem to work fine. I had actually tried it before but I had not added the www. I realise now it  only works with www.

I really appreciate all of your help. Hopefully we can make some firewall changes to allow the non secure version through as we will probably have users with this issue again.

Cheers!

Murray

 

No worries, I'll PM you my email address in case they want a contact to speak to on our end.