Comments
-
Best to open a support case on this.
-
You should be able to do this easily using WSM Policy Manager since you are not connected live to the firewall while making the changes. You upload the changed config after all changes have been made.
-
Are you connecting to the Web UI from one of the VLANs that you are trying to move?
-
What can't be accessed from a SSLVPN user? If you have a domain at your main site, a SSLVPN user when connected is not logged into the domain.
-
I believe that it is the resulting routing that was set up for this BOVPN which is causing this, not the specific policy.
-
If this is a standard BOVPN, I think that all you need to do is to add another Tunnel Local-Remote entry for the desired traffic
-
Via the CLI - there is a Main mode reboot command https://www.watchguard.com/help/docs/fireware/12/en-US/CLI/index.html#en-US/cli_basics/cli_command_modes_intro.html WSM Firebox System Manager - File -Reboot
-
Sorry, no. Consider opening a support case on this. If you find a resolution, please post it. Interestingly, years ago, there was no session timeout for a SSLVPN session - it could go on for days.
-
From the docs: "The FireBox considers all authentication servers other than Firebox-DB as third-party authentication servers. To set the authentication timeout values when you use a third-party server for authentication, you must configure the settings in the third-party server portal." Set Global Authentication Timeouts…
-
A packet capture will show replay packets which is the only way to see them as there is no option to see reply packets in Traffic Monitor.
-
If you have a support contract on your firewall, you can open a support case and get help from a WG rep. You can do this via the Support Center link above
-
You do have the correct printer drivers installed in Windows ?
-
Any ACLs (Access control list) on the switches to which the printers are connected? Anything that you can think of on the printers which may restrict the subnet which can print to them? You can do packet captures (TCP Dump) on the firewall to hopefully see if there are reply packets coming back from the printer(s). If you…
-
Do the printers have a gateway IP addr of the firewall & have the correct subnet mask (/24) ?
-
You can still install WSM Log Server etc. in the latest releases of WSM V12.11 - it is there. You can try installing the Log Server on a Windows PC and see what the limited options are, which should answer your questions.
-
The outgoing packets use the external IP addr of the firewall. So that is what the Internet DNS server should see.
-
Add a Custom Packet Filter for TCP port 515. Add that as a policy From: the wireless subnet or firewall interface name To: the IP addrs of the printers Create or Edit a Custom Policy Template https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/policies/policy_create_custom_c.html
-
I believe that the connection for this WAN on both members should be identical. Please open a support case on this to get WG help in resolving your issues.
-
If you understand, why did you just post a question showing that you don't understand.
-
Yes. BOTH WAN connections MUST be connected to BOTH firewalls. Just like all internal LAN connections MUST be connected to BOTH firewalls. Please read the docs on this.
-
Review this info for Dimension with an external database: Configure the Database Location https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/dimension/database_configuration_d.html WSM Log Server is no longer supported starting in V12.9 of WSM. I don't recall ever seeing info on using an external…
-
Both WANs must be connected to each cluster member.
-
The default setup of a Firebox should allow this. Exactly is not working? What do you see in Traffic Monitor when access to these sites are tried? If denies to the above 2 sites, please post the deny log records. Is there a HTTPS policy in your config now? Is there an Outgoing policy in your config? This should allow out…
-
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