Legacy security technologies are based on a secure perimeter paradigm that implicitly trusts the resources, devices, and people connected to a protected network. Appropriate to network architectures of the 1980s, the secure perimeter has become a liability in today’s decentralized, cloud-based, work-from-home world.
Consider some of VPN’s weaknesses:
Designed for today’s decentralized networks and workforces, ZTNA is based on three core principles:
Assume breach |
Verify explicitly |
Least privilege |
Any network, device, credential, or user could be compromised at any time. Never assume trust for any of them. | Authenticate user identity, confirm device posture, and evaluate the context of every request. | Only authorize access to specific resources the user needs for their work. |
ZTNA is network-agnostic, creating direct connections between users wherever they are located and a company’s resources whether on-premises or in the cloud. Some of the benefits of ZTNA include:
Unified access control | ZTNA lets companies manage access for remote and on-premises workforces within a single system. |
Securing development environments | ZTNA improves the security of a company’s most sensitive resources while improving developers’ access. |
Universal multi-factor authentication | Exium’s ZTNA solution lets you extend MFA to every resource — even to services such as SSH |
Improved security | ZTNA lets you apply granular, role-based access controls based on the principle of least privilege. |
Exium delivers a full-fledged SASE solution with our SASE Cloud (CyberMesh), Cyber Gateways, and endpoint Clients. Additionally, Exium can uplift your existing Firewall deployments by connecting them to the CyberMesh to expand SASE services including ZTNA to your existing locations.
You can connect your existing Firewall to Exium's SASE Cloud by few simple steps
Please follow the step-by-step instructions below.
On Gateways page, Click on ZTNA Firewall Info action in actions column as shown below
Copy following from the popover as shown in below screenshot
On your firewall, configure all the information which is copied at previous step and start the firewall. You are good to go. You should be able to ping the subnets behind your firewall from the devices where exium agent is connected.
NOTE: If given an option to select the IPsec protocol in your Firewall, select IKEv2 (Internet Key Exchange version 2) protocol.
|
IKE encryption algorithm |
IKE authentication algorithm |
IKE SA lifetime |
Diffie-Hellman (DH) group |
IPsec encryption algorithm |
IPsec authentication algorithm |
IPsec SA lifetime |
---|---|---|---|---|---|---|---|
Supported algorithms |
AES 128 AES 256 |
SHA1 SHA2 256 |
28800 sec | Group 14: MODP 2048 | aes-256-cbc | hmac-sha-256-128 | 3600 seconds |
Security Note – For IKE, we strongly recommend to use AES 256 and SHA2 256 to reduce potential vulnerability.
IPsec PFS group:Perfect Forward Secrecy (PFS) refers to the notion that if a session key is compromised, it will permit access only to data of this specific session. In order for PFS to exist, the key used to protect the IPsec SA must not be derived from random keying material used to get the keys for the IKE SA. Therefore, PFS initiates a second Diffie-Hellman key exchange proposing the selected DH group for the IPsec connection to get a new randomly generated key. Supported Diffie-Hellman groups are the same as for IKE.
Enabling PFS is considered to be more secure, but it takes also more time for the exchange. It is not recommended to use PFS on slow hardware.
Note – PFS is not fully interoperable with all vendors. If you notice problems during the negotiation, you might consider disabling PFS.
To learn more about implementing SASE, XDR, IAM, and GRC for your organization and explore tailored solutions that meet your unique requirements, contact Exium at partners@exium.net for a consultation or demonstration. If you are ready to get started, check out our testing and onboarding process.
Customers can use and configure below sample parameters at their end. Parameters might not directly map to customer Firewall's config but they give an idea what configuration is required to make successful connection with Exium's Mesh control.
Parameter | Value | Comment/Remarks |
Connection type | Tunnel | Recommended |
IKE Version | IKEv2 | Both sides of the tunnel must be configured to use the same IKE version |
Connect Mode | Always Connected | Recommended |
Interface | External | |
Local Address | Public IP of WAN interface | Customer side |
Remote Host | Public IP of remote WAN interface | Cybernode IP of Exium Mesh |
Full tunnel mode negotiation | Enable | |
Local Network | The private network(s) attached to the local side of the tunnel | LAN Subnets |
Remote Network | The private network(s) attached to the remote side of the tunnel | Workspace subnet |
Shared Secret | Provided on Exium admin console | |
DPD Interval | In seconds | The no. of seconds to initiate health check message |
DPD Timeout | In seconds | The no. of seconds for a dead peer tunnel to be restarted |
PFS | Disable | |
Phase 1 (IKE/ISAKMP Manual Configuration) |
||
Encryption | AES-256 | |
Hash | SHA-256 | |
DH Key Group | 14 | modp2048 |
Lifetime | 28800 (sec) | |
Phase 2 (ESP Manual Configuration) |
||
Encryption | AES-256 | |
Hash | SHA-256 | |
PFS Key Group | 14 | modp2048 |
Lifetime | 3600 (sec) |
After successful connection, you can check admin console, which will show tunnel status Connected.
If you have Exium client on laptop/machine then try accessing (ping) your private resources. if you observe any issue, we recommend to check the routes on your Firewall. If they look fine, you may try toggling Interface type to External or Custom. External interface type will work after it is refreshed.