Single Secure Website Appears to be Blocked Behind Watchguard T15

Watchguard T15, Ver. 12.5.7.B640389

We are unable to access following website from behind Watchguard T15:


If we bypass Watchguard and connect directly to ISP Modem:

  1. We can browse https://dmz.aclarahosting.com
  2. We can ping dmz.aclarahosting.com
  3. We can ping, (dmz.aclarahosting.com)
  4. Tracert dmz.aclarahosting.com completes trace

When connected to Watchguard:

  1. Cannot browse https://dmz.aclarahosting.com (Site cannot be reached, ERR_TIMED_Out)
  2. Cannot ping dmz.aclarahosting.com or
  3. Nslookup will resolve to dmz.aclarahosting.com
  4. Traffic Monitor indicates Internal IP Allow on port 443 Trusted to External
  5. Under Firewall --> Blocked Sites, Blocked Sites is blank. I setup Blocked Sites Exceptions for: *.aclarahosting.com
  6. Tracert dmz.aclarahosting.com is Timing out at, (last hop prior to 104.37.109.xxx)
  7. Watchguard WAN IP doesn’t appear to be Blacklisted.

Any thoughts or suggestions would be very much appreciated.
Thank you! Chip



  • Options

    Could be a MTU issue. Some web sites don't work with a MTU mismatch - although this does not explain the Ping issue.

    What is your ISP connection type - PPPoE ? Often the MTU is 1492 instead of 1500 which is the default for Ethernet.

    You can check the MTU of your ISP connection by doing a ping to your ISP's
    DNS server, using the -f (do not fragment setting) and the -l payload size
    option, to find the biggest payload that can get to the Internet

    ping xxx.xxx.xxx.xxx -f -l 1472

    A value of 1472 indicates that the MTU is 1500 (there is a 28 byte packet
    header size plus the payload).

    If you get a "Packet needs to be fragmented but DF set." from the ping, then
    decrement from 1472 until you can do a successful ping.
    Then add 28 to that number to get the MTU size for your ISP link.

    If the MTU is lower than 1500, try setting the MTU on the Advanced settings on your External interface on your config, and see if that makes a different.
    Or change the MTU on a PC to that value and see if that helps here.

  • Options

    Also, my tracert last hops are different than yours.

    | 11 | | 10gig-6-5.dbsi-corertr-01.vf.dbsintl.net | | | 0.0% | 50 | 53 | 51 | 1.0
    | 12 | | | | | 0.0% | 50 | 56 | 53 | 1.8
    | 13 | | | | | 0.0% | 51 | 53 | 52 | 0.6
    | 14 | | 104-37-109-155.static.dbsintl.net | | | 0.0% | 51 | 55 | 53 | 1.2
    | 16 | | 104-37-109-144.static.dbsintl.net | | | 0.0% | 51 | 60 | 57 | 2.9

  • Options

    Hi Bruce,
    Thanks for response and detailed information. ISP is Comcast Cable. I followed your instruction and determined MTU of 1460, (1436+28). Changed MTU to 1460 on External Interface. Unfortunately, did not resolve issue. I didn't explain tracert results very well. You are receiving same results when I test directly connected to ISP Modem. When connected to Watchguard, tracert times out at I contacted aclarahosting.com to confirm our WAN IP is not being blocked. Any other thoughts sir?

  • Options

    6 12 ms 11 ms 11 ms
    7 12 ms 11 ms 9 ms ae-501-ar01.denver.co.denver.comcast.net []
    8 10 ms 11 ms 11 ms ae-13.edge8.Denver1.Level3.net []
    9 59 ms 58 ms 58 ms ae-7-7.edge2.Newark1.Level3.net []
    10 64 ms 64 ms 65 ms COLO4-DALLA.edge2.Newark1.Level3.net []
    11 59 ms 59 ms 57 ms te0-0-2-3.dbsi-corertr-b.tek.dbsintl.net []
    12 59 ms 58 ms 58 ms 10gig-6-5.dbsi-corertr-01.vf.dbsintl.net []
    13 60 ms 58 ms 57 ms
    14 63 ms 62 ms 63 ms
    15 * * * Request timed out.
    16 * * * Request timed out.
    17 * * * Request timed out.
    18 * * * Request timed out.

  • Options

    All you know from a "Request timed out" is that the router is not responding to Ping echo requests.
    However, I can't understand why these work when directly connected to your Comcast cable modem and they don't when tried from behind your firewall.

    I have Comcast cable, and I get MTU of 1500 when I test to (Google DNS server) from behind my firewall (T20w). I do have my own cable modem, but i can't see this being an issue.
    What happens if your set the MTU on External to 1500?

  • Options

    Since Ping/tracert packets are small, I don't see how those are a MTU issue.

  • Options

    You didn't mention if you were utilizing a HTTPS Proxy Policy, or a simple HTTPS Packet filter policy.
    If using a Proxy try creating a Packet Filter policy for HTTPS and place it above your Proxy policy.
    If the site loads than the issue lies within the Proxy.

    It's usually something simple.

  • Options
    Thanks for response Bruce & Shaazaminatot. Out of office. Will try suggestions this evening. Appreciate the time!
  • Options

    Good morning Bruce. I set MTU to 1500. Unfortunately, same result.

    Shaazaminator: Correct. I was using HTTPS Proxy Policy. I created HTTPS Packet Filter Policy From Any-Trusted to and tried From Any-Trusted to Any-External with same result. Packet Filter Policy is above HTTPS Proxy Policy.

  • Options

    This issue lies within all PC's on the network correct?
    Would the FB be using any type of web caching server?

    It's usually something simple.

  • Options

    Correct Shaazaminator. All computers on Lan are impacted. We do not utilize a Web Caching Server. We do have BOVPN and BOVPN Virtual Interfaces. However, I disabled all tunnels and same result. We also have SFTP connection to same network,, which fails to connect. It's almost as if we are being blocked somewhere along the line. However, public IP isn't on any Black Lists.

  • Options

    Do you get the same public IP addr when you directly connect to the ISP modem as is used on External?
    If so, then an upstream block on your public IP addr can't be the issue.

  • Options

    I tried the site and WebBlocker stopped it as Uncategorized. I have my proxy set to allow me to click to proceed, and when I clicked, it went to the site without issues.

    Gregg Hill

  • Options
    Bruce. Different static IP. However in same /30 subnet.
  • Options
    edited October 2021

    Work arounds:
    You can add a HTTPS packet filter To: the IP addr of or the DNS name of the site, and on the Advanced tab of the policy you can set the public IP addr to use - the one that works.
    Or you can add a Dynamic NAT entry From: your internal subnet To: the IP addr of the site and specify the working public IP addr to use.

  • Options
    I'll give this a try over weekend. Thanks Bruce! Appreciate the time. Have a great weekend!
  • Options

    Hi Bruce. Unfortunately, unsuccessful with both HTTPS Packet Filter and Dynamic NAT. When you have opportunity, please review my config.

    HTTPS Packet Filter:


    Dynamic NAT:

    Once I understood your recommendation, I really thought this would resolve issue. At the very least, you would think I could ping

  • Options

    The Dynamic NAT entry needs to be at the top of your DNAT entries.
    Currently, at the bottom, it is not being used as higher ones are being used for access to

    Turn on Logging on your HTTPS packet filter so that you can see allows in Traffic Monitor.

    FYI - you don't need to xxx out private IP addrs/subnet as showing them incurs no security issue to you.

  • Options

    Bruce... Do you ever sleep or take a day off. Thanks for responding on the weekend. I moved Dynamic NAT to top. (thanks for educating me):


    Traffic Monitor when connecting to: dmz.aclarahosting.com:


  • Options

    Now you should be able to tracert and have the desired public IP addr be used.
    You should also see the public IP addr being used on the Traffic Monitor HTTPS entry line with this field: src_ip_nat=
    I would expect access to work now.

    Finally you should contact your ISP to have then find out why you can't get to using the firewall public IP addr. Someone out there has an incorrect routing table.

  • Options

    Hi Bruce, Unfortunately we're still unable to connect. Through Traffic Monitor, I confirmed new public IP is being used. Your knowledge and expertise has pretty much validated issue is not related to Watchguard or config. As suggested, I'll contact ISP and start that lovely process. If progress is made, I'll follow-up with resolution. Your time and help has been VERY much appreciated Bruce. Thank you sir!

  • Options

    However, your ability to access this site, tracert to it etc. when directly connected to your cable modem with this other public IP addr and no ability to do this when behind the firewall and using that public IP is still puzzling.

    Check the MTU when directly connected to the cable modem.
    Is there a hard setting on the external interface for MTU in your config?
    Again, a slightly smaller than optimal MTU will not impact/prevent responses for standard ping/tracert

  • Options

    Thanks for hanging in there Bruce. It will be tomorrow/Tuesday before I can take a look. Will let you know ASAP.

  • Options

    Tomorrow - verify the pubic IP addr that you get/use when connected directly to the cable modem.
    If your PC/laptop is using DHCP, you may well get a different one than from your /30 assignment

  • Options

    Hi Bruce,
    Apologizes for delay. As you suspected, WAN IP is in completely different subnet when plugged directly into cable modem. I changed HTTPS Packet Filter --> Advanced --> to Public IP used when directly connected. No luck connecting to dmz.aclarahosting.com. MTU when connected directly to modem is 1500. It appears there is no option to change MTU.

  • Options

    Contact Comcast re. the routing issue.

    There are tools and other options to change the MTU in Windows.
    Check what you get when connected with a PC/laptop - see below.
    Check what you have set on External in your config - Advanced tab.

    For my Comcast cable modem connection, my MTU in my config shows 1500, and access to a Comcast DNS server using the ping process above shows that a MTU of 1500 is good.

    How To: Change and Check Windows MTU Size

  • Options

    Will do Bruce. Thanks for the outstanding technical support and guidance. I'll update "when" we have a resolution.

  • Options

    Was there a final resolution to this? I have the same ISP and am also trying to connect with Aclara. EXACT SAME PROBLEMS!

  • Options

    Have you tried any of the suggestions listed above?

    Anything in Traffic Monitor to help understand this?

    Are you using a HTTPS proxy or a packet filter?

    Seems like an ISP issue as you have the same ISP... and the same issue.
    Looks like bad routing to me if your tracert doesn't go to the correct dest site -

  • Options

    Although I have worked with Watchguard products in the past, I am currently not. I found this thread in a Google search and was amazed at the similarity so I created a community account to see if there was a specific resolution. Thanks for the response.

Sign In to comment.