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:
https://dmz.aclarahosting.com.
If we bypass Watchguard and connect directly to ISP Modem:
- We can browse https://dmz.aclarahosting.com
- We can ping dmz.aclarahosting.com
- We can ping 104.37.109.144, (dmz.aclarahosting.com)
- Tracert dmz.aclarahosting.com completes trace
When connected to Watchguard:
- Cannot browse https://dmz.aclarahosting.com (Site cannot be reached, ERR_TIMED_Out)
- Cannot ping dmz.aclarahosting.com or 104.37.109.144
- Nslookup will resolve 104.37.109.144 to dmz.aclarahosting.com
- Traffic Monitor indicates Internal IP Allow 104.37.109.144 on port 443 Trusted to External
- Under Firewall --> Blocked Sites, Blocked Sites is blank. I setup Blocked Sites Exceptions for: *.aclarahosting.com
- Tracert dmz.aclarahosting.com is Timing out at 216.129.154.5, (last hop prior to 104.37.109.xxx)
- Watchguard WAN IP doesn’t appear to be Blacklisted.
Any thoughts or suggestions would be very much appreciated.
Thank you! Chip
0
Sign In to comment.
Comments
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
unfragmented.
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.
Also, my tracert last hops are different than yours.
| 11 | 69.7.225.45 | 10gig-6-5.dbsi-corertr-01.vf.dbsintl.net | | | 0.0% | 50 | 53 | 51 | 1.0
| 12 | 69.7.236.33 | 69.7.236.33 | | | 0.0% | 50 | 56 | 53 | 1.8
| 13 | 216.129.154.5 | 216.129.154.5 | | | 0.0% | 51 | 53 | 52 | 0.6
| 14 | 104.37.109.155 | 104-37-109-155.static.dbsintl.net | | | 0.0% | 51 | 55 | 53 | 1.2
| 16 | 104.37.109.144 | 104-37-109-144.static.dbsintl.net | | | 0.0% | 51 | 60 | 57 | 2.9
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 216.129.154.5. I contacted aclarahosting.com to confirm our WAN IP is not being blocked. Any other thoughts sir?
6 12 ms 11 ms 11 ms 162.151.8.53
7 12 ms 11 ms 9 ms ae-501-ar01.denver.co.denver.comcast.net [96.216.22.130]
8 10 ms 11 ms 11 ms ae-13.edge8.Denver1.Level3.net [4.68.63.165]
9 59 ms 58 ms 58 ms ae-7-7.edge2.Newark1.Level3.net [4.69.218.41]
10 64 ms 64 ms 65 ms COLO4-DALLA.edge2.Newark1.Level3.net [4.30.130.246]
11 59 ms 59 ms 57 ms te0-0-2-3.dbsi-corertr-b.tek.dbsintl.net [69.7.225.118]
12 59 ms 58 ms 58 ms 10gig-6-5.dbsi-corertr-01.vf.dbsintl.net [69.7.225.45]
13 60 ms 58 ms 57 ms 69.7.236.33
14 63 ms 62 ms 63 ms 216.129.154.5
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
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 8.8.8.8 (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?
Since Ping/tracert packets are small, I don't see how those are a MTU issue.
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.
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 104.37.109.144 and tried From Any-Trusted to Any-External with same result. Packet Filter Policy is above HTTPS Proxy Policy.
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.
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, 104.37.109.144, 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.
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.
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
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.
Hi Bruce. Unfortunately, unsuccessful with both HTTPS Packet Filter and Dynamic NAT. When you have opportunity, please review my config.
HTTPS Packet Filter:
https://drive.google.com/file/d/19Y8Fqf2z5Um5ijWDgvCV8LhQMHhZoDYC/view?usp=sharing
https://drive.google.com/file/d/1szlDKJueYl2QWqQs14xqCYAHtV1HQJSO/view?usp=sharing
Dynamic NAT:
https://drive.google.com/file/d/1uBNcokwLzjrLSTN4nuAT5nFBCoGehkeV/view?usp=sharing
Once I understood your recommendation, I really thought this would resolve issue. At the very least, you would think I could ping 104.37.109.144.
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 104.37.109.144
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.
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):
https://drive.google.com/file/d/1-IAxQ_4wdFHwvI-7XtdWMax4FrB0DjsD/view?usp=sharing
Traffic Monitor when connecting to: dmz.aclarahosting.com:
https://drive.google.com/file/d/1D5qGhQ_LUsv05Niv723h1jT3wEVB7F62/view?usp=sharing
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 104.37.109.144 using the firewall public IP addr. Someone out there has an incorrect routing table.
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!
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
Thanks for hanging in there Bruce. It will be tomorrow/Tuesday before I can take a look. Will let you know ASAP.
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
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.
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
https://becomethesolution.com/how-to-change-and-check-windows-mtu-size
Will do Bruce. Thanks for the outstanding technical support and guidance. I'll update "when" we have a resolution.
Was there a final resolution to this? I have the same ISP and am also trying to connect with Aclara. EXACT SAME PROBLEMS!
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 - 104.37.109.144
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.