TheMachineWhisperer
My feedback
-
79 votesTheMachineWhisperer
supported this idea
·
-
2 votes
An error occurred while saving the comment TheMachineWhisperer
supported this idea
·
-
87 votesTheMachineWhisperer
supported this idea
·
-
452 votes
An error occurred while saving the comment TheMachineWhisperer
commented
In UTM the ability to hide / disable portal categories is really useful for enterprise deployments. This absence of this feature in XG is really notable.
TheMachineWhisperer
supported this idea
·
-
3 votes
An error occurred while saving the comment TheMachineWhisperer
commented
You make a good point about the value of detection and enforcement at switch level.
I'm not sure Sophos getting into expanding their focus from the core endpoint / boundary enforcement into switching would be a good move though. I think Sophos' strength is that it has product focus, it hasn't gone down the route some vendors have e.g. the "Forti-everything" approach.
Looking at methods of integrating Sophos protections from central endpoint / XG with existing best of breed switches might be a better approach. The APIs for XG and central could already be used with vendor agnostic switch management software suites to achieve this.
API says endpoint health has gone red, API knows endpoint IP and MAC, switch management integration to API picks up the change, identifies access port by MAC, applies ACL to port to restrict traffic only to the XG, XG restricts communication only to Sophos to support EDR / endpoint recovery.
Cisco are trying to do something similar as an eco-system with their ISE product.
-
2 votes
An error occurred while saving the comment TheMachineWhisperer
commented
Seconded, ability to create auto-expiring guest SSL VPN profiles with connection number and time restrictions for specific access requirements like temporary supplier remote support would be ideal.
TheMachineWhisperer
supported this idea
·
-
40 votesTheMachineWhisperer
supported this idea
·
-
49 votesTheMachineWhisperer
supported this idea
·
-
9 votesTheMachineWhisperer
supported this idea
·
-
9 votesTheMachineWhisperer
shared this idea
·
-
11 votesTheMachineWhisperer
supported this idea
·
-
10 votesTheMachineWhisperer
supported this idea
·
-
38 votesTheMachineWhisperer
supported this idea
·
An error occurred while saving the comment TheMachineWhisperer
commented
+1 client version too please not just server for features available in the latest OpenVPN client like pull filter
-
8 votesTheMachineWhisperer
supported this idea
·
An error occurred while saving the comment TheMachineWhisperer
commented
+1 But also for SSL VPN connections
-
19 votesTheMachineWhisperer
supported this idea
·
-
3 votesTheMachineWhisperer
supported this idea
·
-
2 votesTheMachineWhisperer
shared this idea
·
-
12 votes
An error occurred while saving the comment TheMachineWhisperer
commented
Agreed.
Anywhere a host entry can be configured should permit all host/group types.
For me specifically FQDN entries should be allowed in Device Access Local service ACL exception rules too.
TheMachineWhisperer
supported this idea
·
-
3 votesTheMachineWhisperer
shared this idea
·
-
453 votes
Adding DHCP options to the GUI is under consideration for a future release.
TheMachineWhisperer
supported this idea
·
An error occurred while saving the comment TheMachineWhisperer
commented
Also need this to encompass being able to push DHCP options via the SSL VPN which does not have a typical DHCP server scope as with normal subnets on physical interfaces.
Seconded.
The current central XG management which automatically uses the local administrator account for XG is not conducive to auditing and segregation of duties.
Changes made are only attributed to the admin account and not recorded in an audit log per-user in central.
The remote management connectivity to XG should either require a separate login to the XG with per-user credentials for the specific user, or should pass through user details from central to the XG for auditing.
At the moment there is no granularity in central management as there is with local webadmin on 4444 where admin roles can be created to delegate access levels per-user.
In advanced use cases it is desirable to provide first line support with access to XG via central, but only with a helpdesk role or low level access to webadmin.