In traditional VPN architectures, the tunnel is usually managed separately from the identity policy. On one side sits the corporate directory; on another, the VPN authentication system; elsewhere, an MFA service; then a separate tool for device trust; and yet another log pipeline for audit. This fragmentation makes remote access operationally brittle rather than secure.
Knowing the correct password is not enough on its own. Is the device managed? Is disk encryption enabled? Is security software current? Is the user in the right group? Is the source IP or time window risky? If these questions are not answered before the tunnel opens, VPN becomes an uncontrolled gateway that extends the corporate network without adequate oversight.
Split tunneling, full tunneling and segment-based access are also not merely routing questions. A finance user and a contractor should not reach the same network; a managed corporate device and a personal device should not carry identical permissions. When tunnel policy is not designed alongside identity, group membership and device trust, the access scope remains broader than it needs to be.
The operational burden compounds the problem. When SSL VPN, IKEv2, MFA, group policy, session logging and SIEM forwarding are each managed separately, the security team cannot see the full picture during an incident. Who connected, from which device, which segments were reached, and why the connection ended should all appear in a single audit trail.
TR7 AAM treats VPN access not as a separate network service but as a controlled remote access layer where identity, MFA, device posture, conditional access and audit decisions converge.
TR7 AAM treats client-based remote access as an identity, device trust and access scope decision — before any protocol is selected.
Users can authenticate via LDAP/AD, RADIUS, OIDC, SAML or a local user source. The same identity decision forms the common policy foundation for client-based access options such as SSL VPN or IKEv2.
The device trust score is treated as part of the conditional access decision. A model that grants broad access to managed devices, restricted access to personal devices and denies access to untrusted devices can be applied.
The TLS-based SSL VPN approach runs over port 443, which eases traversal through corporate firewalls and proxy environments. The choice between split tunneling and full tunnel can be bound to the policy model.
IKEv2/IPsec offers a remote access model compatible with native VPN clients on Windows, macOS, iOS and Android. In scenarios where mobile users switch networks, the IKEv2 approach provides a practical advantage for tunnel continuity.
TR7 SSL VPN and IKEv2 centers the AAM identity, MFA, posture and access scope decision rather than the tunnel protocol itself.
SSL VPN is positioned for access to enterprise resources from restricted networks through a HTTPS/TLS-based tunnel approach. Operating over port 443 provides ease of access in many corporate, hotel, airport and external network environments. This model is particularly valuable when additional clients or custom UDP ports are restricted.
IKEv2/IPsec is suited to enterprise remote access models that are compatible with native OS VPN clients. It can reduce added user-experience complexity on platforms such as Windows, macOS, iOS and Android. In scenarios where mobile users change networks, the IKEv2 architecture offers an advantage for reconnection.
A VPN connection can be evaluated alongside AAM's conditional access policy. User identity, group membership, source IP, time window, device trust and risk signals are taken into the decision process before any tunnel is opened. This approach prevents VPN from becoming an open gate at the network level. The access decision is scoped to the user and device context.
TR7 AAM's MFA approach can be used as a shared trust factor applied to VPN access decisions. Methods such as TOTP, SMS OTP or email OTP strengthen user verification. User experience and security can be balanced with a trusted-device or risk-based authentication model. This reduces the need to operate a separate MFA infrastructure for VPN.
AAM has an identity provider model that can work with LDAP/AD, RADIUS, OIDC, SAML and local user sources. VPN access is not treated as a separate user database or an isolated identity island. Whatever identity a user is managed under in the organization, the tunnel-open decision is bound to that same identity context. This simplifies user lifecycle management.
Which network segments a user can reach can be linked to group membership or AAM user policy. The finance team can be directed only to finance systems, a contractor only to project backends, and the DevOps team only to the development environment. This model reduces the error of granting full network access once a VPN is opened. Tunnel access becomes identity-based segment control.
ETM device posture signals can be used to distinguish managed from unmanaged devices in tunnel access. Disk encryption, security software, patch status or corporate management signals can influence the access level granted. A trusted device can be directed to the full network; a low-trust device can be limited to specific backends only. This approach makes device risk visible in remote access.
VPN sessions can be tied to the audit trail with fields such as user identity, source IP, session time, connection duration and policy outcome. These records can be forwarded to a SIEM and correlated with security events. The operations team can see not just that a connection was opened, but which trust decisions enabled it. This visibility is critical for compliance and incident review.
Split tunneling routes only corporate IP ranges or specific backends through the tunnel; other traffic exits directly. Full tunnel carries all client traffic through the corporate gateway. Which model is applied can be determined by user group, device trust, location or risk level.
If device posture degrades during the connection, the risk score changes or the user policy is violated, the session should be terminated or re-authentication requested. TR7 AAM associates this decision with the conditional access and audit model. This prevents VPN access from becoming a persistent channel that is forgotten once opened. Access should remain observable and revocable throughout the session.
Verified AAM identity capabilities in SSL VPN and IKEv2 should be communicated clearly, alongside the operational requirements of tunnel architecture.
Identity providers, MFA, conditional access and the ETM device posture concept are the reliable foundation of this page. The core message is that VPN is connected to this access engine. The tunnel protocol is positioned as the channel through which identity and policy decisions are applied.
The SSL VPN approach operates over TLS 1.2+ on port 443. This provides an advantage for access from restricted networks. Ease of traversal through corporate firewalls and proxy environments is the practical advantage that stands out compared to IKEv2.
In the IKEv2/IPsec model, UDP 500 (IKE) and UDP 4500 (NAT-T) ports, NAT-T behavior and firewall permissions become critical. The likelihood of being blocked in some restricted networks is higher than with SSL VPN. SSL VPN and IKEv2 are therefore complementary options for different access conditions.
The tunnel IP pool assigned to each session must be planned as part of the VPN architecture. If the pool is exhausted, new connections may be rejected or queued. Pool size and management model should be configured according to deployment requirements.
In VPN access, corporate domains may need to resolve through internal DNS while other domains use external resolution. Split DNS is a natural complement to split tunneling design. This behavior depends on deployment architecture and policy configuration.
Tunnel protocols add header overhead. MTU/MSS adjustment is important especially for IPsec ESP and TLS tunnel performance. Incorrect settings can cause fragmentation, reduced throughput or connectivity problems in some applications.
When an AAM gateway operates in a paired configuration, VPN session failover behavior depends on the tunnel technology. On the IKEv2 side, the mobile reconnection architecture may be advantageous; on the SSL VPN side, VIP design and session continuity must be addressed separately.
A user working from home or while travelling is authenticated through AAM with their corporate identity and MFA. If ETM device trust is sufficient, access to intranet services is granted via SSL VPN; on personal devices, access is limited to narrower segments.
A field technician can connect to the corporate network using the native IKEv2 client on their mobile device. If the device carries a managed profile and a high ETM trust score, broader access is granted; in network-switching scenarios IKEv2 is better suited to mobile use.
A third-party contractor is assigned a user account and a restricted group valid only for the duration of the project. VPN access is opened only to the segment containing the project backends, and all sessions are tied to the audit record.
A factory automation engineer receives a VPN policy that limits access to the OT segment only. Conditional access constrains the decision by shift hours, user group, source IP and device trust; broad access to the general corporate network is not granted.
See the architecture that unifies SSL VPN and IKEv2 tunnels with the AAM identity engine, MFA and ETM device posture. Let us walk through a live setup in your own environment.