¶ How Zero Trust Network Access is replacing VPNs
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:
- Performance impact - VPN gateways concentrate traffic, reduce bandwidth, and increase latency.
- Management complexity - Multiple access control systems complicate security administration
- Visible attack vector - VPN gateways are discoverable and exploitable by hackers.
- Over-permissive access - VPNs grant full access to the protected network’s resources, services, and protocols.
¶ Core principles of ZTNA
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. |
¶ Benefits of ZTNA
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. |
¶ Enabling ZTNA with Existing Firewalls
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.
¶ Connecting your Firewall to Exium's SASE Cloud
You can connect your existing Firewall to Exium's SASE Cloud by few simple steps
- Create Firewall end point on Exium SASE cloud
- Copy the required information from Exium Admin Console
- Configure the Information on your Firewall
¶ Step 1: Create Firewall end point on Exium SASE cloud
Please follow the step-by-step instructions below.
- Navigate to the MSP admin console -> Client Workspace
- Click on Sites in the left menu bar and then click on Cyber Gateways
- Click on Add Gateway as shown below
- On Add Gateway form, Enter a logical name for firewall connection
- Optionally, Enter email-ids to receive notifications for this gateway
- Select Type as ZTNA Firewall
- Enter right subnets - the subnets behind your firewall to which you want to give access from Exium SASE Cloud
- Optionally, Enter the public IP of Firewall to allow connections only from that firewall. If there is no IP, cybermesh will allow connections any IP.
- Optionally, Enter some Notes
- Click on Save as shown below
¶ Step 2: Copy the required information from Exium Admin Console
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
- Workspace Subnet: This is right subnet behind the firewall endpoint on Exium SASE Cloud. All your remote users will access resources behind your firewall using this subnet. You need to configure this on your firewall as right subnet.
- Cybernode IP: This is the firewall endpoint IP on Exium SASE Cloud. You need to configure this on your firewall.
- PSK: Pre share Key needs to be configured on your firewall to connect to exium SASE cloud firewall endpoint.
¶ Step 3: Configure the Information on your Firewall
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.
¶ Sample Configuration Parameters
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 | Point to point or Site to Site | Recommended |
| IKE Version | IKEv2 | Both sides of the connection 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 status Connected.
If you have Exium client on laptop/machine, then try accessing (ping) your private resources. if you observe any issue, we recommend checking 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.
¶ Enabling ZTNA Firewall - Site-to-Site with other gateways
The devices behind ZTNA firewall can be accessed from devices behind Multi-interface (MIF) gateways. To provide this access to subnets (which are part of TP) behind MIF gateways, these subnets should be added ZTNA Firewall definition by following below steps
¶ Step 1: Create Firewall end point on Exium SASE cloud
Please follow the step-by-step instructions below
- On Add Gateway form, Enter a logical name for firewall connection
- Optionally, Enter email-ids to receive notifications for this gateway
- Select Type as ZTNA Firewall
- Enter right subnets - the subnets behind your firewall to which you want to give access from Exium SASE Cloud
- Optionally, Enter the public IP of Firewall to allow connections only from that firewall. If there is no IP, cybermesh will allow connections any IP.
- Enter the subnets (which are part of TP) behind MIF gateways in Allow Access to Other Subnets
- Optionally, Enter some Notes
- Click on Save as shown below
¶ Step 2: Copy the required information from Exium Admin Console
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
- Workspace Subnet: This is right subnet behind the firewall endpoint on Exium SASE Cloud. This will include the subnets which are selected in previous step. The devices which are part of this subnet will access resources behind your firewall using this subnet. You need to configure this on your firewall as right subnet.
- Cybernode IP: This is the firewall endpoint IP on Exium SASE Cloud. You need to configure this on your firewall.
- PSK: Pre share Key needs to be configured on your firewall to connect to exium SASE cloud firewall endpoint.
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.