When a user opens a session on a TS, the profile folders for that session are stored on the TS.
So, if you have access to the TS itself, install the product on the TS device, and all files created on it will be protected.
In other words: if you install the protection on the TS device, all session files created on the TS will be protected.
I Hope this answers your query.
Hi @Alan_Mercer If you have a job posting, I would suggest sharing it with via a job site (like LinkedIn) where WatchGuard maintains a presence. The support forums would not be an appropriate place for that content.
I'm being advised that they sync to their server which is synced via NTP, and so is my gateway server.
There is something definitely amiss though. I have come in today to 2 out of 3 tokens blocked. Looking in the logs they have an authorization and then 10 secs later 2 of the tokens get blocked, no reason given!
I have resynced the tokens in the past as well, just to make sure there is no drift between our gateway and the tokens themselves.
Thanks for your help. I will log a call, even though that seems to be down at the moment.
Since you trust the emails that are being sent, there is no great value in using a SMTP proxy, which could be invoked via the TCP-UDP proxy.
Best practice is to only allow out desired packet types, but doing so is more work.
Many/most small sites don't do this and just use a few proxy policies at most (HTTP & HTTPS).
Power off/on your L3 switch in case somehow the switch has an issue
FYI - you can provide full private IP addresses & subnets without any security exposure to you.
Verify that the L3 switch has an IP addr from the trusted interface subnet.
Check the firewall ARP table (Web UI: Systam Status -> ARP Table) and verify that there is an entry for the L3 switch IP addr and that the entry matches the L3 switch MAC addr.
Verify that there are Network Route entries for any subnet behind the L3 switch, and that those entries point to the L3 IP trusted interface IP addr.
The policy that you see is an Outgoing policy which allows out all TCP & UDP packets, and will allow out TCP port 587.
It is not a TCP-UDP proxy policy.
Explain your DMZ setup.
Did you have something else in place an then swapped in the WG firewall?
If so, details please.
Make sure that the DMZ devices have the correct IP addr, subnet mask & default gateway & a good DNS server IP addr.
FYI - the firewall is not a DNS server, but it can be set up to be a DNS forwarder.
About DNS Forwardinghttps://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/networksetup/dns_forwarding_about.html
You will only see denied packets and proxy strip type packets in Traffic Monitor.
To see allowed packets, you need to enable Logging on policies of interest.
Is your PC getting a an IP addr from the trusted zone?
I'd suggest checking your IP address on your local machine -- DHCP options should not have changed, but some of the older firewalls take quite some time to upgrade. It's possible your computer auto-assigned itself an APIPA address (it'll start with 169.254.x.x usually.)
If that's the case, try unplugging your network cable, and plugging it back in, or doing an ipconfig /release, then ipconfig /renew.
Failing that, I'd suggest opening a support case so one of our support team can help determine what is going wrong.
Also review this Known Issue:
Traffic Monitor fails to show traffic logs after 1 December 2021https://portal.watchguard.com/wgknowledgebase?type=Known Issues&SFDCID=kA16S000000SNhXSAW