Comments
-
No more ideas. Consider opening a support case.
-
One possible reason - if access to 133.149.218.54 is hard coded, then the firewall will not see a DNS resolution for it, and thus will not know that it would match *.gigafile.nu. Another is that some other domain name also resolves to 133.149.218.54, and that was used by the file upload instead of something which matched…
-
Do you have a Feature Key installed on the 12.9.3 firewall? FYI - V12.11 is the latest version of Fireware.
-
Why not have them both on the same policy To: field?
-
I have provided a link which describes how Fireware resolves a FQDN into IP addrs in previous topics from you. Please review it. *.gigafile.nu does not match gigafile.nu There are very likely multiple IP addrs for *.gigafile.nu and just a single IP addr for gigafile.nu
-
So what is different for the web site access and the file upload to cause a different policy to be used for each? What does Traffic Monitor show for both?
-
The firewall routes packets based on IP addr. FQDN entries in policies get resolved to IP addrs. About Policies by Domain Name (FQDN) https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/policies/fqdn_about_c.html
-
Q. Can I make SD-WAN work with HTTP proxy policy? A. yes, but proxy actions can allow, deny or modify contents of the packet. If the packet is allowed, then the SD-WAN action if any, is applied You can't specify a SD-WAN action to a URL, such as FDQN/path. SD-WAN is only for outgoing sessions. What is your exact goal here?
-
You can associate 192.168.13.51 with x.x.x.133 using a 1-to-1 NAT setup. About 1-to-1 NAT https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/nat/one_to_one_nat_c.html
-
Best practice - dual homed devices are strongly discouraged . Disconnect the server trusted NIC and make all traffic to/from it go via a single connection to the firewall, as a DMZ. Set an unused firewall interface to 192.168.13.1 & connect the server external interface to that. Set up the desired policies to allow access…
-
No. But you can specify a URL path on the HTTP proxy action.
-
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/installation/firebox_connect_wsm.html
-
Use the Status user ID with the Read password.
-
Review this article: Detect and mitigate brute force attacks that target Mobile VPN with SSL (SSLVPN) https://techsearch.watchguard.com/KB?type=Article&SFDCID=kA16S000000BcPmSAK&lang=en_US You can increase diagnostic logging for authentication which may show something to help.
-
Add the appropriate policy to allow this traffic - From: IP addr 1 To: IP addr 2. How is the data being transferred? If via Windows file share - the use the predefined SMB packet filter.
-
Consider using WSM Policy Manager for doing this. I consider it easier for bulk actions than the Web UI, especially for proxy actions.
-
I am not seeing this with Edge, on a Windows 10 PC, via this link: https://usa.cloud.watchguard.com/dashboard
-
My AP300 was powered off for way more than 1 year. I plugged it in, and it came right up.
-
I have an old AP300 which I just connected to my T20 running V12.11 and my Fireware config still includes a GWC config which has the old AP300 & AP200. The AP came online & the SSIDs show up on my wireless devices & I can connect to those SSIDs. So, I'm guessing that you can't add old AP devices or old firmware to support…
-
Sequoia V15.0. is not supported yet for SSLVPN. Review the following, or the "Fireware v12.10.4 Update 1 Operating System Compatibility Matrix" in the V12.10.4 Release Notes macOS Sequoia 15.x software compatibility https://techsearch.watchguard.com/KB?type=Article&SFDCID=kA1Vr0000005blJKAQ&lang=en_US
-
What OS version is on your Mac? What version of the SSLVPN client are you using?
-
The Any-external etc. predefined aliases were introduced in V8.0. Discussion at the time, on the long gone user forum at that time, from members of the WG staff, recommended using Any-external etc. instead of the older External etc. aliases because it was thought to be more clear that the new alias would include all…
-
Any-External is a predefined alias. You can select it in the To: field Review this: About Aliases https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/policies/aliases_about_c.html
-
Not needed. Try what I recommended
-
An external version of the config file is in .xml format, in which is very difficult to add additional Domain Names etc. because of the complex format. Exactly what Proxy Action type are you asking about? HTTPS?
-
The reason is that policy 2 specifies a specific WAN interface and not Any-external. Unexpected routing results with Multi-WAN and the use of specific WAN interfaces in the To: field of a policy instead of using Any-external.
-
FYI - this info is in a prior post, here: https://community.watchguard.com/watchguard-community/discussion/4080/policy-set-up
-
As I said in an earlier post - you need to specify Any-external instead of a specific WAN interface on an outgoing policy when using Multi-WAN. Otherwise unexpected routing occurs, such as you are seeing. On policy 2, replace "To:Any-Untrusted,Untrust" with "To:Any-external" and review the results.
-
Also note that 8.8.4.4 is a Google DNS server IP addr, so this is almost certainly DNS over HTTPS (DoH). One can stop use of DoH by settings in ones web browser. Use of DoH seems to be a default setting in most web browsers at this time. Note that the use of DoH prevents monitoring of DNS queries etc. such as by WG…
-
It is not clear IF you are specifying the external interface to use in the To: field from your above examples. If you are doing this, then you must use Any-external instead of a specific WAN interface in the To: field of an outgoing to the Internet policy and use a SD-WAN action to specify the preferred WAN port to use for…