Access failures were resolved by ensuring the required VPN client/profile and any tenant certificates were provisioned and published through the organisation’s self‑service catalogs (Intune Company Portal, IT Service Portal, SelfService) or distributed via packaging channels (PMPC/EPM/paketierung). Support actions included enabling or assigning backend VPN packages and profiles (examples: IU_ResetVPN_1.2 / “Reset VPN”, CPG‑VPN_LOGON, NordLayer, OpenVPN/Azure VPN for macOS, Cisco Secure Client MSIs) and making AWS ClientVPN available in the IT Service Portal when required. Where visibility or installation was blocked, support corrected Azure AD/Entra app and group assignments (including adding the appropriate ResetVPN assignment groups), adjusted Meraki client group deployments when used, unlocked or reassigned catalog entries, and remedied software‑catalog UI rendering issues. Tenant certificates were installed alongside VPN clients to remove “unsecure server” warnings and to allow credential delivery; Safe‑Link secrets, licensing or approval gaps and software‑catalog approval requirements were resolved when they prevented installation. When installer execution required elevated rights, Adminion (Admin Rights App) was enabled or temporary admin rights were granted. Support accounted for Company Portal propagation and device sync delays (commonly ~15 minutes but sometimes longer) and asked affected users to open Company Portal (Apps tab), use Sync and wait for propagation; new or cloud‑only Windows 11 devices sometimes required completion of onboarding steps or a restart before VPN installs or profiles appeared. Some VPN profiles required on‑site provisioning or time‑limited access workflows were delivered via Microsoft My Access Access Packages after approval. Remote troubleshooting, certificate or installer delivery and coordination were performed via Microsoft Teams. After these actions, downstream services (Redshift/legacy DWH, Metabase, DBeaver, Power BI data sources, SMB/WebDAV shares, printers and SSH bastions) became reachable and VPN connections succeeded.

Authentication and reconnection problems were resolved by correcting credential state, client configuration and timing, cached sign‑in state, session timing, local network/router interference, device authentication/certificate state, device provisioning (including VPN client and USB/token setup), and resource authorization. Key observed fixes included:

After applying the appropriate combination of these fixes — addressing client credential settings (including the "use same credentials as Windows" option), performing Okta password resets/account recovery, resetting VPN access/credentials for affected accounts (including during remote support sessions for macOS), using the full IU email username, launching the VPN at pre‑logon, increasing Ivanti session timeout to 630 minutes, disabling autologon/automatic credential reuse, clearing cached OS credentials or rebooting, restarting local routers when interference was implicated, renewing device certificates or reauthenticating devices, provisioning/configuring VPN client and USB/token hardware during device setup, and correcting AD computer account or group membership where needed — affected users were able to authenticate and regain VPN and resource connectivity.

Onboarding and access failures were resolved by ensuring correct license assignment, account mapping and invitation delivery from both the NordLayer admin console and the identity provider. Administrators verified and explicitly assigned NordLayer licenses and group mappings in NordLayer and Okta/AD, re-sent or created account invitations (using alternate addresses such as onmicrosoft.com when iu.org delivery failed), and—where necessary—deleted and re-created accounts or removed and re-added Okta/NordLayer group assignments so users could complete password setup. Password-reset/forgot‑password links and SSO sign‑in were used as alternatives. Self‑service flows that required the Organization/Company ID were satisfied by supplying the ID ('iu_emergingmarketunit'). Users who signed in but saw no gateways regained connectivity after the organization’s booked NordLayer gateways/servers were added to its server lists. Provisioning that was blocked by approval workflows was cleared by reassigning or re-adding the designated approver to retrigger notifications; IT intake generally required a software request including manager approval and a cost center (examples recorded: CC23000, CC13000). Procurement of additional licenses was handled by teams requiring them; documented pricing was roughly $80/year per user and Security did not provision paid licenses in at least one case. Data‑protection/privacy concerns were escalated and reviewed; the data‑protection team reported no objections to NordLayer’s use in the recorded review (including the browser extension). Endpoint install and state conflicts were resolved by provisioning via Company Portal/Intune or the IU Self Service Portal (macOS/Windows), supplying installation guides and links when invitation emails lacked them, and correcting a Windows update package ('NordLayer_Nordlayer_3.6.0_Update') that left Intune reporting installed while Company Portal reported not installed. Support observed that a test AD group (IUG-AD-Nordlayer) sometimes appeared and that visibility in Okta’s dashboard or Software Center did not guarantee a properly mapped license; explicit account invitations and license/group assignments restored access in multiple incidents. Clients stuck on 'connecting with NordLynx' recovered after quitting and restarting the NordLayer client. The NordLayer app was available from the Self Service Portal/Software Center and could be installed without administrative rights when deployed through those portals.

Investigations found services were refusing traffic because the client source IP, VPN egress IP, or upstream provider was not an allowed origin, or because routing and address-space mismatches prevented encrypted traffic from traversing a connected tunnel. Resolutions recorded: allowlisting the client source range or the VPN egress IP at the service (for Azure SQL/Data Warehouse this included adding a firewall rule in the Azure portal or using sp_set_firewall_rule on the master database); moving traffic to an egress IP/country that matched the provider’s allowlist; and disabling or replacing VPNs that egressed from disallowed locations. Several incidents traced intermittent or group authentication failures to ISP/router/CGNAT concurrency limits or upstream provider firewalls that blocked protocols; those were resolved by changing egress provider or tunnel endpoint. One class of failures involved IPSec tunnels that reported 'connected' on appliances (Meraki MX) while encrypted traffic was not visible on the cloud side; those incidents were resolved when office addressing was corrected or when the cloud/VPN routing was updated so office subnets were advertised and reachable. In a few cases teams presented an allowlisted egress by running a local/provisioned tunnel or proxy for third‑party IP‑authenticated licenses, and connections succeeded once the allowlist or egress changes propagated.

Affected devices already contained preconfigured pre‑login corporate VPN/VDI profiles; incidents were resolved by restoring the network conditions or authentication state required for those pre‑login sessions to complete. In multiple cases staff restored a missing CPG‑Corp SSID and removed stale Wi‑Fi entries so the CPG‑VPN‑Logon profile could be re‑added; once devices joined the CPG‑Corp SSID users completed pre‑login VPN/VDI connections via the Windows sign‑in network icon or the CPG‑VPN‑Logon button, which restored access to on‑prem resources and allowed centrally provisioned campus printers to be assigned and installed. Ivanti/VDI sessions that appeared stuck at “Connecting” recovered only after a full VPN session had established before launching the dependent application (one incident recovered after switching to the LIBF‑Staff SSID and waiting ~10 minutes). Several onboarding first‑logon failures produced Error 868 and one‑time‑password authentication failures when users attempted initial sign‑in without using the pre‑login VPN tunnel; those cases were resolved after confirming VPN setup for Windows 10 devices and using the pre‑login VPN tunnel before initial login. Where accounts had been recreated, staff confirmed Okta web access and had users authenticate with their Okta email and password off‑campus; after Okta credentials were confirmed, CPG‑VPN‑Logon button VPN logons succeeded even when an initial taskbar/button connection had failed. Error 809 failures were attributed to mobile‑broadband (Speedbox/nano‑SIM) blocking L2TP; affected users regained VPN access after connecting via an alternate non‑mobile or non‑SIM network. One home‑network case produced Error 868 because the consumer/ISP router had VPN passthrough/VPN support disabled; after the ISP enabled VPN support on the router the RAS name resolution error cleared and the VPN connected. On Windows 11 Early Adopter devices the Windows Hello (PIN/biometric) sign‑in flow prevented the documented pre‑login VPN/VDI login process and required escalation to the specialist team for compatibility or policy decisions.

VPN failures were resolved by multiple privilege, deployment, and delivery workarounds. Windows MSI installers that required elevation were published to the corporate Company Portal and installed as managed/elevated deployments (one deployment was validated for one day); where portal-managed deployment or package publishing was unavailable, one-time administrative elevation was granted so installers, DNS changes, or other system modifications could complete. In cases where a portal-installed client still blocked use because it enforced membership of the local Administrators group or similar local permissions (reported for a WireGuard install), resolution required granting the necessary local rights or performing a privileged installation so the client could run for the user. For macOS where reinstallation produced no usable Cisco Secure Client application, an installer was run on a working Mac and the resulting installation/application files were copied to the target Mac; reinstalling from those copied files produced a usable application. Where users received encrypted or password-protected configuration archives that would not open, the issue was resolved by reissuing the correct password or delivering the configuration by an alternate means. Finally, compatibility gaps (for example, an organisation-standard Cisco Secure Client not supporting WireGuard) were handled by providing an approved alternative client via the portal or addressing permission blockers on the alternative client so the user could connect.

Support inspected the Windows 10 network area and confirmed the VPN status was shown by the top symbol (three connected circles) in the network flyout. The status text read "Connected" when the IU VPN was active. It was also confirmed that the IU VPN required manual connection each morning and did not maintain an automatic persistent session.

Support confirmed the environment had migrated to a cloud‑first model and that most corporate services (Teams, SharePoint, Outlook, Care, MyCampus, EPOS) were reachable without a classic VPN. Repeated Windows 11 cases showed no visible VPN UI and manual attempts to add classic VPNs often failed with RAS/L2TP name‑resolution or server‑not‑responding errors. A small subset of users required VPN for legacy on‑prem resources; on managed devices those legacy VPN profiles (for example CPG‑VPN‑LOGON) were sometimes provisioned or activated in the background so no visible VPN entry appeared. Attempts to dial classic VPN from guest networks commonly produced DNS/RAS resolution failures because internal hosts were not reachable from IU‑Guest. Conversely, VPN services did not establish a tunnel when the device already had internal network access (for example on CPG‑Corp), so no external VPN was required from the office. Wi‑Fi state issues were a frequent cause of on‑site connectivity symptoms — forgetting and rejoining corporate SSIDs (CPG‑Corp/CPG‑Group/eduroam) restored auto‑connect and resolved missing‑network or missing‑VPN‑option behavior. macOS cases with missing credential prompts, inability to remove stored networks, or L2TP errors were escalated to device‑management and identity teams (Jamf/Okta/Active Directory) for profile and Wi‑Fi configuration remediation. Okta Verify functioned only as MFA and was not a VPN client. Requests to provision corporate VPN on personal devices were declined per security policy. Reports of printing failures that previously relied on VPN were traced to legacy printer configurations; printing worked without VPN after correct drivers and network printer configuration were applied. Cases where mapped/network drives appeared unavailable were caused by migration of local/network drives to SharePoint and were forwarded to the specialist SharePoint/drive‑migration team for remediation and password resets. After a VPN portal upgrade some users encountered an unfamiliar remote‑PC login portal: support found the primary connection flow required a bookmarked target computer and a browser plugin that had been blocked, while the alternate connection option was restricted by licensing; support adjusted portal access/plugin/licensing and closed the incidents. Onboarding and training documentation was updated to remove obsolete VPN steps for Windows 11, and remote support (Teams) was used as needed to complete Office installation and resolve sign‑in/setup issues.

On‑site network troubleshooting found the local switch servicing the print server had hung and was making the printer and its web UI unreachable despite active VPN sessions. Restoring the switch's functionality (reboot/power‑cycle or replacement of the hung switch) returned the print server, Dokbox access and Varioprint connectivity to normal.

Investigations found the outage was caused by changes or disconnection of a legacy Azure VPN tunnel that terminated on a Barracuda firewall; a Microsoft-side change and subsequent routing activity altered which outbound traffic the tunnel/firewall allowed or inspected. The legacy VPN connection was rebuilt/re-established and routing was restored; after the tunnel was reconnected, outbound HTTP (port 80) and other previously blocked ports were restored and affected automation workloads resumed. No NIC network security groups had been changed and the Azure VPN Gateway configuration remained otherwise unchanged. A domain controller restart was observed around the outage window in one case, but recovery correlated with restoring the legacy VPN/routing rather than local NIC changes.

Third‑party consumer VPN clients and browser extensions had caused both complete internet loss and application‑specific failures; connectivity was restored in multiple incidents after the consumer VPN was disconnected or removed. One destination returning 403 Forbidden became accessible after the VPN was disconnected (or after the destination was whitelisted while the VPN remained active). A Twilio disconnect (while Salesforce remained reachable) was resolved after browser cache and cookies were cleared and the VPN was deactivated for testing. Where consumer VPN software produced persistent failures (including no internet after a Chrome reinstall), affected users were migrated to corporate VPN access (NordLayer/NordVPN); accounts and licenses were created and assigned and corporate browser‑extension accounts/invitations were provided for geo‑testing. In one case corporate VPN traffic exhibited very slow or failed web and database queries from a user’s home network; the ISP indicated the home link was IPv6‑only and likely interacted poorly with the VPN. That case was temporarily mitigated by issuing a 40 GB eSIM and shipping a smartphone to the user for use as a hotspot, restoring acceptable connectivity while the root cause was investigated.

When the SCCM/Software Center client on the laptop was corrupted, reinstalling the SCCM client restored Software Center functionality; after that the NordLayer package installed successfully and the user was provisioned with credentials/access. Other incidents showed different causes: devices that were not enrolled in Company Portal/Okta or where users lacked local admin rights did not see the NordLayer package in Software Center/Company Portal or could not begin installation. Installation attempts from Company Portal/Software Center sometimes hung, and in one reported case a remote reinstall allowed the package to install but the NordLayer client did not start. Some affected systems also exhibited unrelated symptoms (unexpected removal of TeamViewer, severely degraded battery) and those were escalated to the appropriate hardware/support teams.

A Meraki-based site-to-site VPN was provisioned to replace the unstable Barracuda→Azure tunnel; during the cutover the legacy Barracuda tunnel was intentionally left active as a fallback so user connectivity was preserved while the Meraki link was investigated. The Meraki deployment was documented and troubleshooting showed the Meraki tunnel initially did not carry eduroam traffic while the Barracuda tunnel remained online. The migration surfaced additional eduroam operational issues that were recorded as outcomes of the effort: RADIUS lacked secondary/backup servers and did not have Zabbix monitoring configured; several eduroam-related DNS and Azure group-sync inconsistencies were identified; eduroam CAT location naming and postal-code constraints in the eduroam UK portal were noted; and overlapping Wi‑Fi profiles (CPG‑Corp and eduroam) that caused devices to prefer the wrong SSID were observed. Those findings and the Meraki cutover details were captured for follow-up remediation alongside the VPN work.

The campus-wide incident was escalated to the campus network team; restoration of the CPG_Corp network service resolved RAS name-resolution errors, eliminated VPN logon failures for CPG_VPG-LOGON/CPG-Corp, and stopped the periodic IU‑Study Wi‑Fi disconnects. For intermittent site-level degradations (example: Kiel), support performed network triage — collecting exact locations, SSID, timing, and affected applications — and identified symptoms consistent with upstream WAN issues (local fiber/LWL provisioning or an unstable 5G uplink) that impacted VPN, IU‑Study, VoIP/Twilio and Teams. Those site incidents required carrier/provider and onsite-networking escalation for remediation; no campus-wide configuration change was identified as the root cause in the ticket record.

The Client‑VPN dial‑in node in Datacenter FR2 was reconfigured and then restarted. Following the change and restart, client VPN connections, authentication, and session performance returned to normal. The administrator (Reinhard) validated the recovery and closed the incident.

A support engineer connected to the user's machine via Microsoft Teams and executed a local reconnection script on the Windows 11 laptop. Running that script re-established the VPN client/session and restored remote access.