Comments
-
The problem It is still continuing. However, I typically don't do all that much AD management (ADUC or GPO) while on the SSLVPN, so it's not that high on my radar. I just launch the AD management tool and move on to something else and hope that I remember what I was going to do when it's actually ready for use :D . If I…
-
In my case, the SSLVPN DNS servers are LAN (AD) DNS servers and additionally also the AD DC that is being used to administer AD Users & Computers. My situation is full tunnel. I've never tried it with split tunnel setup
-
Approaching 2 months later, it continues to not work.
-
@Catweazle30169 are you sure that your incoming SSLVPN policy on port 443 does not say From: any external, and instead says from some other public IP address.
-
One other detail for information: while on the SSLVPN, I can RD into any machine at the other end of the SSLVPN and run the AD management tools there and they also run normally. And for the record I just timed opening ADU&C and it actually took nearly 6 minutes to appear! much worse than my earlier guess.
-
Thanks Bruce, I realize that I can deny that way, but I can't come up with a reasonable way to allow (aka whitelist) that way.
-
Another alterative to somewhat protect exchange itself from exposing port 80 directly to the internet is by using a different snat to forward requests on port 80 to a simple apache/ngninx web server that could then do the redirection. *the additional security exposure would be a separate topic. I'm just offering an…
-
I agree, there is no current technical means of preventing this. That's why I've posted this in the Product Enhancement forum - as an enhancement suggestion. ;)
-
I'm not sure how ACL's could be used to prevent a legitimate SSLVPN user from using his personal computer. And what I'm suggesting is MFA with the approved computer being one of those factors.
-
It is a known issue with no workaround https://watchguard.force.com/customers/wgknowledgebase?type=Known%20Issues&SFDCID=kA10H000000g64FSAQ&lang=en_US