504 errors and Block actions when Web Filtering On...

These 500-series errors usually are resolved by skipping as you have done.  Some can be resolved by creating an exception for anti-virus, so you might try that.

However, I'm not able to reproduce this behavior with slashdot on 8.308.  Perhaps others can comment on 9.004...

Cheers - Bob

Those sites work fine here, web filtering enabled, 9.004-34 firmware; also no complaints at any customer sites running the same combination.  One key difference, none of them are using AT&T DIA ... a few AT&T U-Verse customers (small business VDSL) though.  I will say that AT&T's routing and peering is one of the biggest messes I've ever seen as an outside observer; generally I've found that a traceroute to a site or IP over AT&T typically (well, a lot of the time) has almost double the hops of any other ISP my customers use.  My guess would be some sort of intermittent routing or peering issue on their end.

One thing to check just came to mind though; make sure that the speed and duplex of the interfaces on the UTM that connect to your AT&T CPE equipment match; a mismatch can result in very wierd stuff happening (I just remembered a customer on Comcast Cable that had a similar issue, with a particular set of sites; in the end it was the new CPE equipment having a speed and duplex issue -- set them to match and voila it was fixed)...

Go into the shell on the UTM and run ifconfig ethx (where x is the interface number of the AT&T connection) and look for errors...

Thanks for the responses Bruce and Bob.  I tracerouted slashdot this morning and it was 13 hops.  It didn't seem overly ridiculous but each hop did respond.  55ms was the highest time on one hope that I can remember from then.

I thought about errors or carrier issues so I had already checked that.  When we switched to them, we were having carrier errors (flapping) and matching up the duplex eradicated that as you said.  This 

Here's the eth1 ifconfig:

asg1:/home/login # ifconfig eth1

eth1      Link encap:Ethernet  HWaddr 00:1A:8C:12:3F:0D

          inet addr:XX.XX.XX.XX  Bcast:XX.XX.XX.XX  Mask:255.255.255.240

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:372265 errors:0 dropped:0 overruns:0 frame:0

          TX packets:458063 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:111225366 (106.0 Mb)  TX bytes:108014066 (103.0 Mb)

          Interrupt:18 Memory:feae0000-feb00000

For giggles I pulled an ethtool on it:

asg1:/home/login # ethtool eth1

Settings for eth1:

        Supported ports: [ TP ]

        Supported link modes:   10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Full

        Supported pause frame use: No

        Supports auto-negotiation: Yes

        Advertised link modes:  1000baseT/Full

        Advertised pause frame use: No

        Advertised auto-negotiation: Yes

        Speed: 1000Mb/s

        Duplex: Full

        Port: Twisted Pair

        PHYAD: 1

        Transceiver: internal

        Auto-negotiation: on

        MDI-X: off

        Supports Wake-on: pumbg

        Wake-on: g

        Current message level: 0x00000007 (7)

                               drv probe link

        Link detected: yes

I even had AT&T go as far temporarily removing the access list and they did a dump of me trying to pull that site and found they were only blocking one thing, some traffic on port 5060 from the outside trying to get in.  

Bob, I thought about the antivirus setting so I turned it off and ran the tests again and found that the header of the page would load but anything below that would fail.

I ran:

cat http.log |grep -c Timeout

and got 1050



cat http.log |grep -c 502

and got 339

If I have to add a ton sites to the skiplist, anyone have a quick grep method to get a unique list out of that?  My grep "fu" is a little weak.

Is this a bug?  It was failing before upgrade to UTM 9 as well (8.306+).

I like Bruce's explanation, and so I did the following traceroutes from centralops.net to your IP (mods can see the IPs of the posters), my IP and the company website.

Cheers - Bob

Ugh, I just realized the error is a statuscode="504" error and not a 502 error.  And, of course, I can't edit the subject line.

Bob, I PM'd you the site's IP address.  The site I'm posting from is not the one having the problem.  I manage 6 different locations that all have UTM devices.  That one is the only one on AT&T's IP Flex product though.  Everything else is fiber, cable or some other provider's bonded T1s.  

My thought that maybe it had to do with a DNS issue.  He had me adjust the forwarders on the DNS server to openDNS addresses, clear the cache and try again.  No-go there either -- same result.

I'm open to other ideas, or if someone has an awesome grep command to get me the last week's worth of 504's so I can create one large skip list for them that would be great...

Use the 'Search Log Files' tab to find all of the recent 504s.  The tools at Free online network tools - traceroute, nslookup, dig, whois lookup, ping - IPv6 are useful to get information like this.  I PM'd the result for the client's IP - it looked better than the far-right one above for my company's website, so that's not the problem.

What does Support have to say about this?

Cheers - Bob
PS I'll correct the subject line.

Thanks for the update.  

I haven't hit support with it yet, my reseller has to submit it I think.  He has all of the pertinent info but wanted me to try a few things first.  I'll let you know what they find.