Comments

  • My advice would be to get a decent endpoint product loaded on the Server like EPDR or something to have a better chance detecting Zero days. That and having a decent third-party spam filter that can help monitor email in transit for you.
  • I don't believe so. That is traditionally used to manually authenticate so that you can do things like group-based Internet policies/ group-based firewall rules. I have seen some instances where administrators used this to externally "authenticate" and then RDP straight into machines but this is ill-advised when compared…
  • The original ticket I made was years ago when I worked at a different company so I unfortunately do not have the reference. I am sorry.
  • I advise getting the exact destination of the services having issues and using a packet filter for that specific traffic while leaving the FTP Proxy to handle other generic un-encrypted traffic. I advise this so that you are still scanning unencrypted stuff while not breaking critical Services.
  • Are your users assigned to the group? You would need to check this by going to: Setup > Authentication > Authentication Servers After this you would need to double-click on the user (Or click user once and click _edit__), and make sure that SSLVPN-Users is in the Member: column: If that doesn't work I would see what…
  • You would simply add an Any-Deny rule that denies traffic from SSLVPN-Users that goes to SSLVPN Subnet (By default the SSLVPN Subnet is 192.168.113.0/24) Make sure that rule is on top of the Default SSLVPN traffic rule and you should be golden. (If in auto-order mode it should automagically add it above the Default SSLVPN…
  • Most of this is covered under EPDR training videos as all "EDR Core" is, is the "EDR" piece from EPDR but provided by firewall licensing rather than EDR licensing. If you are a WG partner I advise you go to learn.watchguard.com and review the Endpoint Security Essentials course. This course and the study guide that comes…
  • You could use the SD-WAN graphs in Dimension or Cloud Visibility https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/WG-Cloud/Devices/reports/report_interface_summary.html?cshid=16049
  • > @"james.carson" said: > I'd suggest creating a support case so that one of our support team can assist. I put in a request for them to fix documentation on filter ID (see above comments) I did this a while back and it seems the documentation is still not updated... considering how the steps are very similar I am…
  • If this were for a new setup, my advice would have been to setup a test sync group to do the invites and to notadd anyone to that group except your test users. Once done then you can roll-out by using real groups. The only caveat to this is when it comes to the SAML integration with Microsoft 365 as that is an "all or…
  • I would check the built-in SSL VPN rule and see if “Any-Trusted” is listed as a SOURCE along with “Any-External”. I’d check both configs before and after the firmware upgrade and compare the settings on that policy in particular.
  • https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/services/tdr/tdr_host_sensor_enforcement.html
  • > @"Tristan.Colo" said: > I am hoping that soon they are going to enable "WatchGuard EndPoint" enforcement (which has agents that work fine on Linux!) Note that they did end up making it so that you can enforce users to use the right VPN settings and such via EPDR as of a few months ago. That’s the main solution I’m aware…
  • To my knowledge WatchGuard does not provide public access their roadmaps beyond their technicians saying there is one when we open tickets/ discussions. I may be wrong (who knows maybe things have changed) but I’ve never seen their roadmap published anywhere to the general public for any of their product lines.
  • The release notes includes a OS compatibility chart. https://www.watchguard.com/support/release-notes/WatchGuard_Cloud/en-US/index.html#en-US/TDR/OS_compatibility.html?TocPath=Threat%2520Detection%2520and%2520Response%257C_____5 The answer is “no” it can only be installed on CentOS6 or CentOS7. That said, TDR over time is…
  • One of the things that may help "Control the Chaos" is to consolidate IPs into an Alias and go from there... It is traditionally better to use Aliases (Even if for one FQDN or IP Address) so that: * * You know what the IPs are for * * Scalability as you can use the Alias in multiple rules instead of a blob of IPs in…
  • I don't know I have never used the Livebox. You would need to ask the Vendor for the Livebox appliance on how that stuff works because it seems like the appliance probably double-NATs anything you put behind it. I have never used the solution before so anything I'd have to say would be pure speculation unfortunately.
  • That sounds like it should work then as it just connects to the wireless network to get on the LAN according to your notes. Routes only matter if that stuff is behind another network on another gateway which it seems it is not. If it can get on the network usually then the WG should be able to support it as the WG is just…
  • I believe you are right when it comes to Full Tunnell'd VPN solutions as DNS Watch will happen as everything routes through. However, on split tunnel traffic anything that goes to public DNS will bypass the WG filtering completely (from what I have seen in my deployments) which seems to be the issue RalphtheMac is trying…
  • Even more-so.... if you have EPDR already DNSWatch Go is kind of Moot since the WebCategories on EPDR are the exact same. If you wanted a WG Endpoint solution for better protection I would advise EPDR... it is better bang for your $$$ and does more than simple providing a web-filter for your agents. Plus, it seems to be…
  • If it works anything like POE then it should work... or I don't see why it wouldn't. What does CPL stand for? As long as that stuff communicates on your current LAN then the WG should support that stuff too as long as it doesn't require routes. IE if it is on the network already and getting across then the WG should work…
  • Sounds like a potential issue with the home ISP. Have you tried SSL VPN to see if that's handled better? Some ISPs filter VPN traffic a lot unless it is SSL-VPN since that usually operates over 443. It may also be good to run a wireshark Packet capture from the computer when the traffic is misbehaving on the client network…
  • IKEv2 is the best VPN for security and performance but requires RADIUS (or AuthPoint). SSLVPN is nice in places where IKEv2 traffic isn't allowed since it runs off HTTPS which isn't usually blocked by Firewalls in public places.
  • WatchGuard patches the vulnerabilities in later firmware updates. I do advise updating your firewall to the latest firmware to mitigate any major HTTP vulnerabilities that they are aware of. Otherwise I also advise blocking Non-US countries from accessing the VPN Policy using Geolocation. ~T
  • You are correct, if you block one you will block the other as they operate off of the same port/protocol. Why would you care about the VPN logon page being allowed? If your firewall stays patched all Web-related vulnerabilities should be accounted for... This and MFA would be the best advice as far as security is…
  • > @mashiyer said: > Thanks Tristan. I tried that but it seems I cannot adjust the timeout between push notifications. The failed attempts seem to be logged only when the username or password entered is incorrect. > Also it seems "Login Attempts" setting does not apply to users synced from an external identity which we're…
  • If you go to this document and go to 12.6 or lower for the windows sever directions it is identical to what the steps should be if you do the new AuthPoint integration. The steps you are looking for are 23-27:…
  • Yeah WG’s documentation is missing the Filter ID step if you do the direct AuthPoint integration with IKEv2. I put in a support request to add this missing step as it’s caused confusion on several deployments from my teammates.