That is the way that it works for BOVPNs to non-AWS sites.
You have a few ways around this:
-Some email providers will allow [email protected] to specify a folder by doing something like [email protected] to specify a folder to sort email into. If your server supports this, authpoint treats it like a unique email.
-If you own your own domain, you can alias another user (like [email protected]) to the same mailbox, and use that one.
Authpoint requires what it believes to be a unique email for each user, so each email is going to count as two accounts inside of authpoint, and be two tokens per phone.
An Internet search for openvpn 10060, shows 10060 is a Windows socket error, most likely a timout.
No specific help for understanding the cause of this.
Could be dropped packets someplace I guess.
I created a feature request for you to enable forcing token security on a users' phone. That ID is AAAS-12911.
Currently there is no control over 3rd party tokens, because they are 3rd party. A user with the correct activation code or barcode can activate a 3rd party token on multiple devices. Trying to restrict it at the authpoint app doesn't provide any additional security.
Simply put, if you or your users/customers want/need to access a HTTPS web site which does not work with Inspect enabled, you only have 1 choice - don't inspect traffic to that web site.
CVE-2020-5902 is for a product of F5 networks. I'd suggest following whatever guidance F5 provides related to patching that product.
The article also links an issue related to Citrix Netscaler, for that exploit, I'd suggest checking with Citrix to ensure that your environment is patched.
It appears that patches have been developed for most of the issues in that bulletin, so patching them would be the most effective way to mitigate the issue.
It's also worth noting that you can make a more advanced policy that has a few -and- options in it.
In the from field of your policy, if you go to:
-WebUI, Add -> Find Custom in the type drop down.
-Policy Manager, Add -> Add Other, choose Custom from the drop down.
You can add something like the group -and- the interface the user needs to come from.
It really depends on which applications and features you are looking for. For example, in order to protect Windows machines with Azure MFA, you will need to buy a license that includes Windows Hello for Business, that can get very expensive.
AuthPoint supports both Windows and Mac logon protection (online and offline), for computers, servers, and RDP, as well as SAML applications, VPNs (including IKEv2 which is the fastest and more secure), etc.
About hardware tokens, AuthPoint Hardware Token can only be used with AuthPoint. They are manufactured by WatchGuard, and the seeds - the most important thing you need to protect - are securely transferred from the production site to WatchGuard Cloud. There is no risk of seeds exposure, you just activate them in your tenant.
So if you use Azure MFA and plan to use OATH hardware tokens, it seems (from the page you mentioned) that you have to provide the seeds in open format. Anyone can copy and paste into an OATH TOTP generator, thus creating a token clone. AuthPoint supports OATH TOTP tokens, but we always suggest to import in PSKC format (RFC 6030), to protect them. Have one person receive the pskc file, another one receive the transport key.
Expiring the lease makes the mgmt server reach out to the firewall and effectively poke it, and asks it to check in. May mean that the firewall has incorrect setting (wrong IP, etc) for the mgmt server, or something else.
-On the firewall that isn't checking in, search the traffic monitor logs for "dvcp" -- any errors there might shed some light on what the problem is.
-Make sure that the firewall has the correct management server IP in Setup -> Managed Device Settings.
-Make sure that the firewall in front of the management server is allowing the external traffic into the management server. Many admins will change the policy from any-external to a list of their managed firewalls -- this might need to be updated if you've done that.
If you keep running into the issue, opening a support ticket would probably be the next step to fixing it.
Turn on Logging on any policies which you think will allow this access so that you see access attempts in Traffic Monitor.
You can test this access using the SSLVPN client from behind the firewall.
Make sure that the Dynamic NAT settings still have the 3 private supernets and that one of them includes the SSLVPN virtual IP subnet.