Best Of
Re: Watchguard cloud - too much data
Also, not being able to see diagnostic log messages immediately is also a negative.
Not obvious why this is the default here, since supposedly only authorized people can see the WG cloud logs.
"WatchGuard Cloud stores diagnostic log messages sent by a Firebox, but they are not visible in Log Manager or Log Search. If you need to troubleshoot an issue, you can request these diagnostic log messages from WatchGuard Technical Support."
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/WG-Cloud/Devices/reports/log_manager_wgc.html
Re: Watchguard cloud - too much data
So , i opened a case and apparently there was a change in February to limit the amount of data. Now with my timeframe set to even 1hr i can't see my top blocked clients.
This severely restricts how useful the WG cloud is. Might have to resurrect Dimension.
Abertay
Status Page
Hi all,
Can we get a status page for all the WatchGuard products, with the option to sign up for alerts.
I know DNSWatch has one already. (https://status.dnswatch.watchguard.com/ )
Aron
Re: Status Page
I'd still want a status page like dnswatch so I can automatically get alerts straight to slack, email or webhook to give us a heads up in advance, we mainly log straight into cloud not the support portal.
Aron
Re: issue with "Watchguard firebox SSL VPN " client on a MAC.
How are you trying to access the servers?
Via SMB?
If so, could SMB not be enabled in the wireless interface?
Re: Header Line too Long
"I first expand it to 16384 in the proxy action"
What is "it" that you expand?
"I then switch off the option "Set the maximum URL path length to " and the error is still there."
Maximum URL path length and header line length are not the same and are in different parts of the settings.
Shouldn't you be making the changes in HTTP Proxy Action > HTTP Response > General Settings > "Set the maximum line length to"?
My "Set the maximum line length to" in that area is 7000 and "Set the maximum total length to" is unchecked. I have no problems loading the web page.
Re: Unable to download IKEv2 client profile
Seen this same problem....
Are you using a 3.party certificate with IKEv2?
If you are, the problem is probably a missing Root certificate.
Re: Implications of disabling the built-in IPSec policy
@Bruce_Briggs
The tunnels can end up in a state where they'll start /if/ the firewall starts the tunnels, but if they're started from the remote side, they'll fail (with an error from that side like message retry time out, or similar.) Things like rekeys or connection blips from the remote side will also break the tunnel. It'll sort of work, but make an overall bad experience.
Re: Implications of disabling the built-in IPSec policy
Given what James said, and what is in the docs (see below), I would expect the BOVPN tunnels to stop, or at the least, not be able to start up once stopped.
Disable or Enable the Built-in IPSec Policy
The Firebox includes a built-in IPSec policy that allows IPSec traffic from Any-External to Firebox. This hidden policy enables the Firebox to function as an IPSec VPN endpoint for Branch Office VPN and Mobile VPN with IPSec tunnels. The built-in IPSec policy has a higher precedence than any manually created IPSec policy. The built-in IPSec policy is enabled by default. To disable this policy, clear the Enable built-in IPSec Policy check box. Do not disable the built-in policy unless you want to create another IPSec policy to terminate a VPN tunnel at a device other than the Firebox, such as a VPN concentrator on the Firebox trusted or optional network.
If you clear the Enable built-in IPSec Policy check box, you must create IPSec policies to handle inbound VPN traffic to the Firebox and any other VPN endpoints.
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/bovpn/manual/global_vpn_settings_about_c.html
Re: Implications of disabling the built-in IPSec policy
@MattHX
It'll break all tunnels (IPSec Mobile, or Site to Site.) In order to get it working again, you have to re-check that box (which just makes a hidden policy that says.
Any-External -> Firebox (for ESP, AH, port 500/UDP and 4500/UDP)
[Firebox is just an alias for every IP the firewall owns.]
Established connections will continue, and any tunnels initiated by the firewall may continue, but anything coming from the other end will end up in the bit bucket.
By disabling the rule and making a rule like
Any-External -> 65.66.67.68 (made up IP) (for ESP, AH, port 500/UDP and 4500/UDP)
You're telling the firewall to only listen for IPSec Traffic on 65.66.67.68 instead of every IP it owns.
You can then make another rule with
Any-External -> (SNAT) 65.66.67.69 - SNAT -> 192.168.111.100 (internal L2TP server)
Which would effectively make any IPSec traffic pointed at 65.66.67.68 terminate at the firewall
and
any traffic pointed at 65.66.67.69 at the L2TP server.