VIA Release Notes

Select any of the VIA client platforms to view release notes for VIA releases supporting devices of that type.

VIA 3.4.1 for Windows

Features

Support for L2 VPN/Secure Boot on Windows 10 Clients

VIA 3.4.1 is enhanced to support 64-bit clients running the following Windows releases while using Secure Boot operating mode.

Windows 10 Enterprise LTSC 2019

Windows 10 Enterprise 2016 LTSB

Windows 10 Enterprise 2015 LTSB

In previous releases, some Windows 10 clients would receive the error “A digitally signed driver is required: Windows blocked the installation of a digitally unsigned driver” when installing the VIA client.

This feaure is only supported on clients running 64-bit versions of Windows 10. Clients running 32-bit versions of Windows should not upgrade to this release of VIA, and should remain on VIA for Windows 3.2.x.

Known Issues

Table 1: VIA 3.4.1 Known Issues
Bug ID	Description
VIA-2286	Symptom: Clients that upgrade to supported versions of Windows 10 after installing VIA 3.4.1 are not able to use the L2 VPN functionality. Scenario: The L2 VPN functionality is not supported on Secure Boot mode in clients running Windows 7 or Windows 8. The VIA driver does not install this feature on Windows 7 or Windows 8, so support for this feature is not available after the client upgrades to Windows 10. Workaround: Upgrade a Windows 7 or Windows 8 client to a supported Windows 10 Enterprise release, then reinstall VIA 3.4.1 to use L2 VPN functionality.
VIA-2314	Symptom: Windows 7 and Windows 8 clients display the error message "Windows can't verify the publisher of this driver software" when installing the VIA application. Scenario: This error message occurs only during initial installation, and will not impact the installation process. Workaround: Accept the error message by selecting the Install this driver software anyway option. The VIA client will operate as expected after installation.
VIA-2315	Symptom: VIA 3.3.0 and later releases fail to install on clients running 32-bit versions of Windows 10. Scenario: The L2 driver introduced in VIA 3.3.0 Windows edition does not correctly operate with 32-bit clients, and will fail to install. Workaround: Clients using 32-bit Windows 10 versions should remain at VIA 3.2 releases.

Resolved Issues

Table 2: VIA 3.4.1 Fixed Issues
Bug ID	Description
VIA-1883	Symptom: A VIA client may fail to correctly auto-connect after the client wakes from sleep mode. Scenario: This issue was caused by a delay in the client's ability to obtain a valid IP address upon waking from sleep mode, and is resolved in VIA for Windows 3.4.1.
VIA-2194	Symptom: VIA clients displayed the error message "Aruba virtual adapter could not be configured" when attempting to connect. Scenario: This issue impacted clients running Window Enterprise v1709 or v1803, and is resolved in VIA for Windows 3.4.1.
VIA-2201	Symptom: VIA clients displayed the error message “ISAKMP stack could not be initialized” when attempting to connect. Scenario: This issue is resolved for Windows clients in VIA for Windows 3.4.1.
VIA-2248	Symptom: VIA failed to connect on Windows clients authenticating using a smart card with an ECDHE certificate. Scenario: This issue is resolved for Windows clients in VIA for Windows 3.4.1.
VIA-2257	Symptom: Windows VIA clients that authenticated using a smart card with an ECDHE certificate did not correctly fail over to a secondary server. Scenario: VIA 3.4.1 for Windows resolves an issue where the VIA application could fail to respond when the connection failed over to the secondary server defined in the client's VIA connection profile.

VIA 3.4.0 for Windows

Features

Support for One Time Password authentication using IKEv2

VIA 3.4.0 introduces support for One Time Password (OTP) authentication in IKEv2 flows. When enabled, this feature supports a higher level of security associated with IKEv2 by requiring users to authenticate their VPN connections using OTP rather than using a certificate or pre-shared key. Previous releases of VIA for Windows supported the use of OTP authentication with IKEv1 only.

This feature is supported on VIA 3.4.0 when deployed in conjunction with ArubaOS 8.5 or later and ClearPass Policy Manager 6.7.7 or later. For the highest level of security, best practices also includes establishing a RadSec session between the ArubaOS controller and the ClearPass Policy Manager server to secure traffic between these devices.

To enable OTP authentication using IKEv2, you must configure EAP-GTC as the authentication method on the ArubaOS controller:

1. In the Managed Network node hierarchy, navigate to Configuration > Authentication > L3 Authentication.

2. In the VIA Connection Profile, select eap-gtc from the IKEv2 Authentication method drop-down list.

3. Click Submit.

4. Select Pending Changes.

5. In the Pending Changes window, select the check box and click Deploy changes.

IKEv2 Flows have Increased Fault Tolerance

VIA 3.4.0 provides greater fault tolerance for network outages due to events such as a down network adapter, an unplugged network cable, or an unreachable ArubaOS controller. If a network disruption is resolved in less than a minute, the VIA IKEv2 session can continue without disruption. If the disruption lasts a minute or longer, the session is disconnected.

During the first minute of a network disruption, VIA displays the following modified icon the system tray to warn users of a potential disruption to their current session.

Figure 1 VIA warning icon

VIA 3.3.2 for Windows

Resolved Issues

Table 3: VIA 3.2.4 Fixed Issues
Bug ID	Description
137108 177232	Symptom: VIA failed to connect correctly and displayed the error "Aruba virtual adapter could not be configured." Scenario: This issue impacted clients running Windows 10, and occurred when VIA's attempt to configure an IP address on a virtual adapter took longer than 15 seconds, causing the operation to time out.

VIA 3.3.1 for Windows

Features

Support for Layer-2 Forwarding

VIA 3.3.1 and ArubaOS 8.4 introduces support for end-to-end layer-2 connectivity, allowing VIA to connect devices in the same Layer-2 network and operate in a similar manner to an Aruba Remote Access Point (RAP).

Starting with ArubaOS 8.4, the VIA connection profile on the controller includes a new Use L2 Forwarding option which can be selected to enable Layer-2 forwarding. (This feature is disabled by default.) When this feature is enabled on the controller and the VIA client has made a VPN connection to the controller, the VIA client will activate its internal virtual-hardware L2 adapter. The traffic generated by this adapter will then be routed to the controller for processing, allowing the VIA client to send GRE packets containing Ethernet frames using the IPSec tunnel already established with the controller. GRE packets received from the IPSec tunnel are then processed and forwarded according to the L2 routing rules on the controller. All L2 packets destined (as per client MAC address) to the VIA client are also processed and encapsulated in a GRE packet over the IPSec tunnel.

Best practices is to avoid enabling the Use L2 Forwarding option and the Enable Split Tunneling feature at the same time. The L2 forwarding feature will impact the behavior of the split tunneling feature, so devices using both these features simultaneously will operate in a mode more like full tunnel than split tunnel. But this is not a known issue, but an effect of the design of these features.

VIA 3.3.0 for Windows

Features

VIA Client Displays Last Logon Date

This Release of VIA for Windows introduces a new security enhancement that displays the date and time of the previous VIA login for that client each time the VIA client is successfully connected. This information appears on the Home screen, as well as the Settings > Network window in the VIA Client GUI. If VIA is running in minimized mode, (either because it is configured to always be minimized or it has been minimized by the user) and VIA appears as a system tray icon, the previous logon date and time appears as a popup balloon message above the system tray once the VIA connection is complete.

Support for SSO-Based Authentication for VIA Profile Download

VIA 3.3.0 for Windows supports Security Assertion Markup Language (SAML) Single-Sign On (SSO), allowing VIA to manage VIA client access based on the attributes in the SAML response issued by the authenticating identity provider (IDP). When this feature is enabled and a VIA user submit a username and password through the VIA client, the VIA user is redirected to an external IDP for authentication. The Aruba controller then uses the attributes returned during the SAML assertion to derive the role and/or dynamic ACLs for that VIA client. The following new parameters have been added to the VIA authentication profile to enable this feature in ArubaOS 8.0.1.0-SP.

Table 4: VIA Authentication Profile Parameters to Support SAML SSO.
Parameter	Description
SSO based authentication for VIA Profile download	Select this option to enable SSO-based authentication for clients downloading a VIA profile. This feature is disabled by default.
Enabled SSO redirect URI and port	Use this parameter to direct the request to a service provider URI. By default, ClearPass Policy Manager functions as the service provider for SAML, and can redirect the user to a ClearPass authentication page, or the authentication page of an external IDP.
SSO ACL server host	IP address or Fully Qualified Domain Name (FQDN) of the external ACL server.
SSO ACL server configuration	The ACL server configuration parameter requires the following information for the remote server: Server user name Server password Server URI Server Port

New vendor settings have also been added to ClearPass Policy Manager to support this feature. Starting with ClearPass Policy Manager 6.7.5, the Web Logins configuration includes the new vendor settings template Single Sign On – VIA VPN Client. Once this is template configured and the IP address of the controller is added to the template, the client will always be authenticated will always against the SAML IDP configured in CPPM. After authentication, the following parameters are sent to <controller>/via/sso.

sso_user – username entered by the user in the SAML IDP

sso_cookie – SSO cookie

VIA 3.2.4 for Windows

Resolved Issues

Table 5: VIA 3.2.4 Fixed Issues
Bug ID	Description
137108 177232	Symptom: VIA failed to connect correctly and displayed the error "Aruba virtual adapter could not be configured." Scenario: This issue impacted clients running Windows 10, and occurred when VIA's attempt to configure an IP address on a virtual adapter took longer than 15 seconds, causing the operation to time out.

VIA 3.2.3 for Windows

Known Issues

Table 6: VIA 3.2.3 Known Issues
Bug ID	Description
VIA-1976	Symptom: Domain Pre Connect (DPC) fails in VIA 3.2.3. Scenario: When the DPC feature is enabled on the connection profile, VIA tries to connect when the user logs out or restarts the machine.

Resolved Issues

Table 7: VIA 3.2.3 Fixed Issues
Bug ID	Description
137108 177232	Symptom: VIA authentication failed when there were certain extended Latin characters in the password. Scenario: If there were certain extended Latin characters (like é è ç ô) in the password, VIA authentication failed. Changes to ArubaOS 8.3 and VIA 3.2.3 resolve this issue. ArubaOS 8.3.x and later releases now provide a configuration option in the VIA authentication profile that allow you to configure the encoding format types. (Available types are UTF-8 or ANSI, and the default is UTF-8.) VIA 3.2.3 can extract the encoding format type received from the controller and convert client user credentials into the received encoding format type.
174951	Symptom: The VIA client window popped up even when the user connected to a trusted network. Scenario: When a client connected to a trusted network, the VIA client popped up and stayed idle. When a client connects to an untrusted network, the expected behavior is that the VIA client shall connect and then minimize to the client's system tray. However, in a trusted network, since the VIA client does not connect as per design, it stays idle. Enhancements to VIA 3.2.3 allow the VIA client window to minimize to the client's system tray after it detects a trusted network.
180822	Symptom: VIA 3.2.2 introduced an enhancement to ensure that all local subnet traffic to and from a client using full tunnel mode was securely routed through the VPN tunnel. However, this feature did not address the scenario where the client’s gateway IP address was same as the DHCP server's IP address. Scenario: Further improvements in VIA 3.2.3 ensures that all local subnet traffic to and from a client using full tunnel mode is securely routed through the VPN tunnel, even when the client’s gateway IP address is same as the DHCP server IP address.

VIA 3.2.2 for Windows

Features

3.2.2 Supports Simultaneous Installation with OnGuard

The VIA 3.2.2 installer is enhanced with additional settings that allows a user to install and use both VIA 3.2.2 and ClearPass OnGuard 6.7.2 on a single client. This feature requires that both VIA and OnGuard be installed with a specific flag that allows them to coexist on a single device.

To use this feature, OnGuard must be installed by passing the AllowBothVIAAndOnGuard flag to the installer in the following format:

ClearPassOnGuardInstall.exe /AllowBothVIAAndOnGuard=1

msiexec /i ClearPassOnGuardInstall.msi ALLOWBOTHVIAANDONGUARD=1

In addition, VIA must be installed with the AllowBothVIAAndOnGuard flag in the following format:

msiexec /i Aruba-VIA-3.2.0.0.XXXXX-64(86).msi ALLOWBOTHVIAANDONGUARD=1

Both OnGuard and VIA must be installed with this flag in order for them to coexist on the same system. If either of them is installed without this flag, the other cannot be installed.

Resolved Issues

The following issues are resolved in VIA 3.2.2

Table 8: VIA 3.2.2 Fixed Issues
Bug ID	Description
176782 VIA-1673	Symptom: The virtual adapter was incorrectly disabled at the end of the IKE rekey expiry interval, causing VIA users to be disconnected. Scenario: This issue occurred when the IKE rekey process failed to complete properly. This issue is resolved in VIA 3.2.2.
167475 43439	Symptom: When a VIA VPN client attempted to send traceroute messages, the controller did not respond to traceroute diagnostics with the expected ICMP expired in transit message. Scenario: The issue occurred when a controller failed to properly handle packets with a lower time- to-live (TTL) value when processing them through a VIA VPN, dropping packets with a TTL value equal to or lesser than 2. This issue and resolved by improvements to how VIA manages the TTL value of outgoing Encapsulating Security Payload (ESP) packets.
169506 41157 43847	Symptom: In previous releases of VIA, VIA clients connected in full-tunnel mode could incorrectly send and receive traffic from the local default gateway or other devices in the same subnet as the default gateway. Scenario: Improvements in VIA 3.2.2 ensure that all local subnet traffic to and from a client using full-tunnel mode is securely routed through the VPN tunnel.
169679 42555	Symptom: Clients were not able to authenticate to the network with VIA smart card authentication using a certificate with a PIN. Scenario: Improvements to VIA certificate selection resolves an issue identified in an earlier release of VIA, where clients were unable to authenticate to network using a smart card with a certificate and a PIN, causing the transaction to fail.
172889 43675	Symptom: When a client attempted to download a VIA profile using RSA SecurID next token authentication, the profile failed to download. Scenario: Improvements in VIA 3.2.2 ensures that the VIA client sends the correct VIA authentication profile information during the connection attempt, ensuring that the correct authentication server and server group verifies the password generated by the RSA token.
VIA-1694	Symptom: VIA failed to choose the previously chosen certificate for a connection created using a connection profile with Domain Pre-Connect (DPC) enabled. Scenario: If a client device with multiple certificates imported into the machine store downloaded a connection profile with DPC enabled, the certificate used by the device to create an initial connection might not be selected again if the user signed out and then signed in back again.

VIA 3.2.1 for Windows

Resolved Issues

Table 9: VIA 3.2.1 Fixed Issues
Bug ID	Description
42862	Symptom: VIA did not display an appropriate message when a new token is needed for authentication. Scenario: If a user enters three consecutive incorrect passwords, the RSA token/DUO requires that the user enter the correct token code twice for authentication to succeed. Starting with VIA 3.2.1, the GUI displays the following text message informing users about this issue: Wait for token to change, then enter the new token code.
169679	Symptom: VIA Smartcard authentication fails to admit users with valid certificate and PIN credentials. Scenario: This issue was observed in VIA 3.2.0 when users attempted to sign in using Smartcard authentication.

VIA 3.2.0 for Windows

Features

This feature allows an administrator to preload the VIA Installer with preselected controller addresses. Upon installation, VIA will automatically display the list of controller addresses from which users can download their profile, freeing users from the task of manually entering in the information for the controller.

To embed this profile information into your VIA installer package:

1. Download the build “ansetup64.msi” or “ansetup32.msi” from the Aruba support site to a temporary folder.

2. Create the file GatewayList.xml in the same temporary folder and populate that file with XML data in the format of following example

<?xml version="1.0"?>

<Name>Controller-ONE</Name>

<CertFilteringCriteria>certificateIssuer=customer-1-WIN-XSHSQH1EKMR-CA</CertFilteringCriteria>

</VPNController>

<Name>Controller-TWO</Name>

</VPNController>

</VPNServerList>

</MultiProfileConfig>

3. Download the file GenerateCustomVIAinstaller.bat from the Aruba support site into the same temporary folder as the previous files.

4. Install the NSIS (Nullsoft Scriptable Install System) tool to generate the custom executable file. The file “nsis-3.01-setup” can be downloaded from http://prdownloads.sourceforge.net/nsis/nsis-3.02.1-setup.exe?download.

5. Use the following command to generate the custom executable file

GenerateCustomVIAinstaller.bat Aruba-VIA-3.2.0.0.96992-64.msi GatewayList.xml

6. Using this example, an executable VIA installation file file with the name “Aruba-VIA-3.2.0.0.96992-64” is created in the same temporary folder.

7. When you run the executable installation file, the VIA UI will display VPN server entries with the controller name(s) configured using the <Name> parameter in the xml script in step 2. The user much select a controller and a controller certificate , then click Proceed.

8. If the user has a certificate which is not verified, a certificate warning will appear. (This is an expected behavior). In this case, the user must click Continue in the warning message box before profile will be downloaded.

Resolved Issues

Table 10: VIA 3.2.0 Fixed Issues
Bug ID	Description
37246	Symptom: Clients were unable to use the following CLI commands to connect, disconnect, and exit from VIA: connect disconnect exit Scenario: This issue was observed in all versions prior to 3.2.
161832	Symptom: When a client attempts to login from a non-domain device, VIA becomes stuck in the connection phase. During this time, the Connect/Disconnect button appears gray and is inactive when the user selects it. Scenario: This issue was observed in VIA 3.0.0.
159914	Symptom: Clients running a 64-bit version of Windows 7 were randomly unable to connect to VIA after selecting a certificate during authentication. In rare cases, the certificate selection prompt might reoccur until the window was closed. Scenario: This issue was observed in VIA 2.3.1.
156633	Symptom: Clients running Windows 7 or 10 experience random spikes in memory usage from the process arubantsvc.exe while disconnected from VIA. Scenario: This issue was observed in VIA 3.1.0.

VIA 3.1.0 for Windows

Resolved Issues

Table 11: VIA 3.1.0 Fixed Issues
Bug ID	Description
152432	Symptom: VIA was unable to download VPN profiles while connecting to a Dell controller image. Scenario: This issue was observed in VIA 2.3.4.
152428	Symptom: VIA UI logs displayed the incorrect time format between the hours of 1200 and 1300. Scenario: This issue was observed in VIA 3.0.0.
155318	Symptom: Domain Pre-Connect (DPC) failed to initiate when users rebooted or logged off their devices after establishing an IPsec connection. Scenario: This issue was observed in VIA 3.0.0.
157858	Symptom: VIA crashed during VPN profile download. Scenario: This issue was observed in VIA 3.0.0 when users attempted to establish a VPN connection using a server URL (FQDN) on devices running Windows 7 or Windows 10.

VIA 3.0.0 for Windows

Known Issues

Table 12: VIA 3.0.0 Known Issues
Bug ID	Description
36226	Symptom: The old VIA app icon fails to change to the new VIA 3.0.0 app icon. Scenario: This issue is observed even after uninstalling an older version of VIA and installing VIA 3.0.0 or upgrading from an older version of VIA to VIA 3.0.0. Workaround: In Windows 7, issue the ie4uinit.exe –ClearIconCache command in the command prompt. In Windows 10, navigate to C:\Program Files\Aruba Networks\Virtual Internet Agent, rename anuacui.exe to a name of your choice, right-click the file and select Send to Desktop. The client must reboot the device for this change to take effect.
36649	Symptom: The keep VIA window minimized feature fails to work in VIA 3.0.0. Scenario: This issue is observed even after enabling the Keep VIA window minimized parameter in the controller. This is a limitation in VIA 3.0.0. Workaround: None.
37246	Symptom: The following CLI commands are not supported on the VIA 3.0.0 installer: gateway authprofile getconfig user password nocertwarn Scenario: This issue is observed in VIA 3.0.0. Workaround: None.
38940	Symptom: Proxy settings are not available in VIA 3.0.0. Scenario: This issue is observed in VIA 3.0.0. Workaround:VIA uses proxy settings from Internet Explorer to connect to the network.

VIA 3.1.5 for macOS

Known Issues

Table 13: VIA 3.1.5 Known Issues
Bug ID	Description
VIA-2333	Symptom: Issues in MacOS 10.15 prevent VIA from connecting when using personal identity verification (PIV) authentication. Scenario: VIA 3.1.5 does not support authentication using a smart card on clients running macOS 10.15 Catalina. Workaround: Use pre-shared key (PSK) or certificated-based authentication. There is no workaround for this available in VIA, but this issue does not impact clients using smart cards while running earlier versions of macOS.
VIA-2360	Symptom: Local web proxy servers continue to be used when a VIA VPN is active on macOS Scenario: When a web proxy server exists on the same subnet as VIA clients, the connection will continue to be used despite the activation of the VIA VPN.

VIA 3.1.4 for macOS

Features

Support for SSO-Based Authentication for VIA Profile Download

VIA 3.1.4 for macOS supports Security Assertion Markup Language (SAML) Single-Sign On (SSO), allowing VIA to manage VIA client access based on the attributes in the SAML response issued by the authenticating identity provider (IDP). When this feature is enabled and a VIA user submits a username and password through the VIA client, the VIA user is redirected to an external IDP for authentication. The Aruba controller then uses the attributes returned during the SAML assertion to derive the role and/or dynamic ACLs for that VIA client. The following new parameters have been added to the VIA authentication profile to enable this feature in ArubaOS 8.0.1.0-SP.

Table 14: VIA Authentication Profile Parameters to Support SAML SSO.
Parameter	Description
SSO based authentication for VIA Profile download	Select this option to enable SSO-based authentication for clients downloading a VIA profile. This feature is disabled by default.
Enabled SSO redirect URI and port	Use this parameter to direct the request to a service provider URI. By default, ClearPass Policy Manager functions as the service provider for SAML, and can redirect the user to a ClearPass authentication page, or the authentication page of an external IDP.
SSO ACL server host	IP address or Fully Qualified Domain Name (FQDN) of the external ACL server.
SSO ACL server configuration	The ACL server configuration parameter requires the following information for the remote server: Server user name Server password Server URI Server Port

New vendor settings have also been added to ClearPass Policy Manager to support this feature. Starting with ClearPass Policy Manager 6.7.5, the Web Logins configuration includes the new vendor settings template Single Sign On – VIA VPN Client. Once this is template configured and the IP address of the controller is added to the template, the client will always be authenticated will always against the SAML IDP configured in ClearPass Policy Manager. After authentication, the following parameters are sent to <controller>/via/sso.

sso_user – username entered by the user in the SAML IDP

sso_cookie – SSO cookie

Resolved Issues

Table 15: VIA 3.1.4 Fixed Issues
Bug ID	Description
VIA-2105 VIA-2086 192777	Symptom: VIA did not display an appropriate message when a new token is needed for authentication. Scenario: If a user enters three consecutive incorrect passwords, the RSA token requires that the user enter the correct token code twice for authentication to succeed. Starting with VIA 3.1.4, the GUI displays the following text message informing users about this issue: Wait for token to change, then enter the new token code.

VIA 3.1.3 for macOS

Features

Support for macOS Mojave (10.14)

VIA 3.1.3 Mac^® Edition supports devices running macOS Mojave (10.14). The Apple VPN framework requirements for this macOS release requires that Mac devices update to VIA 3.1.3 Mac^® Edition by downloading the VIA application directly from the Apple App store. Client devices are no longer be able to download and install an updated VIA release through the controller, and the VIA external download URL and Allow client to auto-upgrade settings in the VIA connection profile do not apply to this release.

Client devices that are not connected to the internet or are unable to connect to the Apple App store will not able to upgrade to this latest version of VIA for macOS. The application has been renamed from Aruba Virtual Intranet Access to Aruba VIA and will appear under this name in the Apple App store and in the applications list once installed on the client.

Upgrading From an Older VIA Release to VIA 3.1.3 Mac Edition

To upgrade a Mac client from an earlier release of VIA for Mac to VIA 3.1.3 Mac Edition:

1. Uninstall the earlier version of VIA for Mac.

a. Exit the VIA application.

b. Navigate to Applications and select Virtual Intranet Access.

c. Right click the icon and select Move to Trash to uninstall VIA.

2. Download the VIA 3.1.3 Mac Edition installation package from the Apple App store.

3. Launch the VIA 3.1.3 Mac Edition installation process to install this latest version of VIA for macOS.

4. The configuration profile used by the older version of VIA for Mac is automatically available for VIA 3.1.3 for macOS. The configuration profile used by the older version of VIA for Mac is automatically available for VIA 3.1.3 for macOS. A privacy policy message appears during the installation process. Click Accept.

5. If the Client Auto-Login option is enabled, a message appears asking if the user wants to add the VPN configuration. Select the Allow option to continue and complete the connection process.

Installing VIA on a Client with no Existing VIA Software

To install VIA 3.1.3 Mac^® Edition on a client that does not have any VIA client currently installed:

1. Download the VIA 3.1.3 Mac Edition installation package from the Apple App store.

2. Launch the VIA 3.1.3 Mac Edition installation process to install this latest version of VIA for macOS.

3. Download the profile and connect.

VIA 3.1.1 for macOS and earlier releases are not supported on macOS 10.14 and are prevented from completing a VPN connection. Users with clients running macOS 10.14 should uninstall VIA 3.1.1 for macOS and install VIA 3.1.3 for macOS as described in the section above to allow VIA to work on 10.14.

Downgrading to an Earlier Version of VIA

Downgrading from VIA 3.1.3 for macOS to earlier versions of VIA is not recommended. If you install a downgraded version of VIA, you will see two VIA icons and two VIA GUIs on your client. To complete the downgrade, to uninstall the older version of VIA as described in Upgrading From an Older VIA Release to VIA 3.1.3 Mac Edition.

Known Issues

Table 16: VIA 3.1.3 Known Issues
Bug ID	Description
174023	Symptom: Local DNS resolution does not work when using split-tunnel VPNs on devices running macOS. Scenario: Internal software changes have resolved this issue, but VIA 3.1.3 supports local DNS resolution only if Internal domains are added to the DNS suffix list in the VIA connection profile.

VIA 3.1.1 for macOS

Known Issues

Table 17: VIA 3.1.1 Known Issues
Bug ID	Description
174023	Symptom: Local DNS resolution does not work when using split-tunnel VPNs on devices running macOS. Scenario: After upgrading to VIA for macOS 3.1.0 or later releases, users may be unable to resolve DNS entries on the local network. Workaround: None

Resolved Issues

Table 18: VIA 3.1.1 Fixed Issues
Bug ID	Description
43498	Symptom: VIA clients running OS X with the language set to Turkish can now use VIA to connect to the network. Scenario: Internal enhancements resolve an issue identified in previous releases that could prevent OS X Turkish language clients from connecting.
34634	Symptom: VIA clients can properly reconnect to a network using a profile with MSCHAPv2 authentication and the Save Password option enabled. Scenario: An issue is resolved that prevented a client from reconnecting when the client used a MSCHAPv2 profile with the Save Password option enabled and the client's login password was changed on the RADIUS server. The next time the client used VIA to connect to the network, VIA attempted to use the saved password, and authentication failed.
32882	Symptom: The maximum timeout setting in the VIA connection profile can now be disabled. Scenario: The max-timeout parameter in the ArubaOS VIA connection profile supports a setting of 0, which disables this feature. This feature is supported by ArubaOS 6.5.x and ArubaOS 8.x.
32699	Symptom: VIA 3.1.1 resolves an issue that could cause VIA to stop responding if an invalid certificate was selected. Scenario: If a user selects an invalid certificate, VIA 3.1.1 displays an error message and allows the user to select a different, valid certificate, but does not stop responding.

VIA 3.1.0 for macOS

Known Issues

Table 19: VIA 3.1.0 Known Issues
Bug ID	Description
174023	Symptom: Local DNS resolution does not work when using split-tunnel VPNs on devices running macOS. Scenario: After upgrading to VIA for macOS 3.1.0, users may be unable to resolve DNS entries on the local network. Workaround: None

Resolved Issues

Table 20: VIA 3.1.0 Fixed Issues
Bug ID	Description
39606	Symptom: A VIA client crashed on macOS after the server information is changed from the initial domain to an IP address of a VIA connection profile. Scenario: This issue was resolved in VIA 3.1.0.

VIA 3.0.2 for macOS

Known Issues

Table 21: VIA 3.0.2 Known Issues
Bug ID	Description
149813	Symptom: Users are unable to access the Intranet after the VPN connection is established on VIA. Scenario: This issue is observed in Mac devices with VIA 3.0.1 when split tunneling is enabled on the VIA connection profile used to establish the VPN connection. Workaround: None.

Resolved Issues

Table 22: VIA 3.0.2 Fixed Issues
Bug ID	Description
150163	Symptom: The Network tab of the VIA UI displayed an incorrect remote server hostname for each VIA connection profile when multiple connection profiles were configured. VIA used the configuration information of one controller for all network adapters. This issue is resolved by ensuring the configuration information is retrieved from the controller selected for the connection. Scenario: This issue was observed in VIA 3.0.0 on devices using Mac OS X El Capitan and macOS Sierra.

VIA 3.0.1 for macOS

Known Issues

Table 23: VIA 3.0.1 Known Issues
Bug ID	Description
35554	Symptom:VIA profile gets deleted after upgrading Mac OS X from 10.11.5 to 10.11.6. Scenario: During Mac OS X upgrade, the VIA profile is stored in a temporary location. Mac OS X uses an OS API to retrieve the VIA profile post the upgrade, but returns empty. Workaround: Reboot the system multiple times after upgrade. This sometimes makes the API return proper details, hence recovering the VIA profile.

Resolved Issues

Table 24: VIA 3.0.1 Fixed Issues
Bug ID	Description
34558	Symptom:VIA obtained an old profile. This issue is resolved by deleting the backup copy of the old VPN configuration files from the temporary folder after VIA installation is successful. Scenario: This issue was observed after uninstalling and reinstalling VIA. This issue was observed in Mac clients running VIA 3.0.0.
34035 139483	Symptom:VIA continuously requested for administrative credentials. This issue is resolved by adding a VPN service which runs as daemon(root) and handles all VPN configuration modification requests from VIA client. Scenario: This issue was observed when the password was changed for a downloaded profile on a non admin user. This issue was observed in Mac machines with VIA 3.0.0.
34009	Symptom:VIA requested for credentials on every connection although save password was enabled. The fix ensures that VIA retrieves the saved password successfully and connects automatically. Scenario: This issue was observed when the user changed the credentials for the profile under use. This issue was observed in Mac machines with VIA 3.0.0.
33880	Symptom: CPU usage of the VIA process was high even when there was no traffic passing through the tunnel. This issue is resolved by VIA checking whether the application needs VPN status update or not. For example, if VIA is running in the background or minimized then, updating the VIA UI is not required. Scenario: This issue was observed when VIA UI was updated even when VIA was minimized. This issue was observed in Mac machines with VIA 3.0.0.

VIA 3.0.0 for macOS

Features

Resolved Issues

Table 25: VIA 3.0.0 Fixed Issues
Bug ID	Description
28221	Symptom: VIA 2.0.4.0 UI failed to respond when the Cancel button was clicked while downloading a profile. This issue is resolved in VIA 3.0.0. Scenario: This issue was observed occasionally in Mac OS X with VIA 2.0.4.0.
28391	Symptom: The Assigned IP / Mask and Packet Traffic fields were blank although VIA connection was established. This issue is resolved with the new VIA 3.0.0 UI. Scenario: This issue occurred intermittently on VIA 2.0.3.0 on Mac OS X clients.
29454	Symptom: When there was a role mismatch, the VIA client did not update the new profile. This issue is resolved by implementing internal code changes. Scenario: This issue was observed when the server or the Active Directory set a different role than the initial role. The client profile failed to get updated with the new profile according to the new role. This issue was observed in VIA 2.0.3.0 and 2.0.4.0.
29473	Symptom:VIA failed to connect with SHA1-160 for hash in IKE crypto map. This issue is resolved by implementing internal code changes. Scenario:This issue was observed in Mac OS X with VIA 2.0.4.0.
30217	Symptom: When Send Logs button was clicked, VIA failed to attach the log file. This issue is resolved by implementing internal code changes. Scenario:This issue was observed in Mac OS X 10.11 clients with VIA 2.0.4.0.
30672	Symptom:VIA failed to establish VPN connection with IKEv1 certificate authentication. This issue is resolved by implementing internal code changes. Scenario:This issue was observed when client certificate had multiple intermediate CA. This issue was observed in VIA 2.0.4.0.
31131	Symptom:VIA failed to respond. This issue is resolved by implementing internal code changes. Scenario:This issue was observed when VIA 2.0.4.0 was detecting network after the Mac OS X machine woke up from sleep mode.

Resolved Issues

Table 26: VIA 3.1.1 Resolved Issues
Bug ID	Description
VIA-2374	Symptom: In VIA deployments with controllers running ArubaOS 8.2.x, setting a VIA Message of the Day (MotD) banner with more than 1247 characters could prevent Linux clients from downloading the VIA profile. Scenario: The issue only impacted Linux clients trying to download a VIA profile. Clients that had already downloaded the profile were able to properly connect despite the large banner message file.
VIA-2359	Symptom: Logon/logoff scripts failed to work properly on clients connecting using the VIA command-line interface. Scenario: In previous releases, logon/logoff scripts could only work properly on VIA clients connectiong through the VIA GUI. This issue is resolved in VIAfor Linux 3.1.1.

VIA 3.0.1 for Linux

Features

Support for Smart Card Authentication

VIA 3.0.1 introduces support for smart card authentication. Smart cards provide two-factor authentication for IKEv1 Cert, IKEv2 Cert, and IKEv2 EAP-TLS using a certificate and PIN number.

To establish a VPN connection using a smart card:

1. Configure the smart card device with a Public-Key Cryptography Standards (PKCS) library using the standard procedure, and then configure the PKCS module path in the /usr/share/via/via_config.xml file as follows:

<cryptoki_lib_path>:

#cat /usr/share/via/via_config.xml

<via_config_profile>

...

<cryptoki_lib_path>/usr/lib/ libeTPkcs11.so</cryptoki_lib_path>

...

</via_config_profile>

2. Launch VIA and download a certificate-based VPN connection profile.

3. Plug the card reader into your device.

4. Click the VPN connection status ring on the VIA home screen to connect VIA.

5. Navigate to the VIA Cert Store tab.

6. The list of available certificates, including certificates from the smart card, is displayed.

7. Select the certificate, and then click Select.

8. Enter the smart card PIN number when prompted to Enter storage password.

9. Click OK. The VPN connection is established.

VIA 3.0.0 for Linux

Features

Auto Config in VIA

VIA 3.0.0 introduces the auto-config feature, which allows a user to saves configuration settings in a configuration file that VIA can use to establish an IPsec session. A copy of the configuration file template, via-default.cfg is available in the /usr/share/via/ folder. A user can copy this file template to a local folder and modify the settings as required.

Once the configuration file (via-default.cfg) is ready, use the via-cli load <config-file path> command to load the configuration. If <config-file path> is not specified, VIA looks for the configuration file in the current folder. If the configuration file is not found, the VIA looks for it in ~/.via. If the downloaded profile is marked as auto connect, VIA attempts to connect and uses the configuration file for any inputs.

The following table lists the parameters in VIA configuration file:

Table 27: Configuration File Parameters
Parameter	Description	Input Type
ProfileGateway	IP address or host name of the server from which, VIA downloads the profiles	String
ProfileUsername	Username for authentication to download the profile	String
ProfilePassword	Password for authentication to download the profile	String
ProfileAuthenticationProfile	VIA authentication profile to select if there are multiple profiles	String
ProfileIgnoreWarning	Ignores any HTTPS warnings while downloading the profile if set to yes [Y]	Char [Y/N]
CertificateStoreKey	Certificate store key is used when importing certificates	String
CertificateDeleteAll	Deletes all existing certificates before importing new certificates	Char [Y/N]
CertificateImportPrivate	Imports a given pfx or p12 certificate and certificate encryption key separated with comma. Appened multiple entries separated by semicolon.	String
CertificateImportPublic	Imports a given cer or der certificate. Appened multiple entries separated by semicolon.	String
AuthUsername	Username for XAUTH or MSCHAPv2	String
AuthPassword	Password for XAUTH or MSCHAPv2	String
AuthPIN	Used if the certificate is enclosed with a subsystem that uses PIN (for example: smartcards)	4-digits numeric
AuthCertificateSubject	Identifies the certificate to be used for authentication	String
AuthConnect	Connects after profile download when set to yes [Y]	Char [Y/N]
RouteEnable	Enables client side routing when set to yes [Y]	Char [Y/N]
RouteNetworks	IP address of the subnets. Appened multiple IP addresses separated by semicolon.	-

VIA Gateway

Ensure the IKEv2 Configuration Payload Support for VIA Clients feature is enabled in the controller running ArubaOS 6.5 or later. This feature has been implemented in the following two topologies:

Simple Setup

This section describes the prerequisites and procedure to setup. The following figure shows a simple setup for VIA gateway:

Figure 3 Simple Setup for VIA Gateway

Prerequisites

Linux Client machine running Ubuntu 12.04/14.04/16.04 , CentOS 6, or RHEL 6

Controller running ArubaOS 6.5 or later

The IKEv2 configuration payload support for VIA clients (CFG_SET) feature is enabled in the controller. Refer to ArubaOS 6.5.x User Guide for more details.

CFG_SET is supported only on ArubaOS 6.5 or later

Procedure

1. In the controller, configure IKEv2 VIA profile.

2. Install VIA 3.0.0 on the Linux machine.

3. In the controller, enable VIA subnet routes by running the crypto-local isakmp allow-via-subnet-routes command.

4. Use either VIA configuration file (see VIA Release Notes) or manual operations to install and connect to VIA.

5. Disconnect VIA using the via-cli vpn disconnect command.

6. Set the routable networks using one of the following ways:

If you are using the auto configuration file, update the configuration file and set RouteEnable=Y and also set the RouteNetworks appropriately. Force load the configuration using the via-cli load config command.

If you are connecting VIA using UI, update the /usr/share/via/via-updated.conf and add RouteEnable=Y and RouteNetworks values. Connect to VIA.

7. VIA sends an INFORMATIONAL-CFG_SET with given subnets, as shown below:

Aug 14 17:44:42.686 [VPN INFO config_loader():config_loader.c:152] Loading cached configuratin file /usr/share/via/via-updated.conf

Aug 14 17:44:42.686 [VPN INFO config_loader_load_subnets():config_loader.c:253] Route Networks(0):192.168.1.0 (108736)

Aug 14 17:44:42.686 [VPN INFO config_loader_load_subnets():config_loader.c:253] Route Networks(1):255.255.255.0(16777215)

Aug 14 17:44:42.686 [VPN DEBUG LOG_from_mocana():log.c:678] I -->

Aug 14 17:44:42.686 [VPN DEBUG LOG_from_mocana():log.c:678] CFG_SET

Aug 14 17:44:42.686 [VPN DEBUG LOG_from_mocana():log.c:678] IP4_SUBNET(192.168.1.0 /255.255.255.0)

Aug 14 17:44:42.686 [VPN DEBUG LOG_from_mocana():log.c:678] spi={cb37cdce891b8db5 26f868cf9efd78ce} np=E{CP}

Aug 14 17:44:42.686 [VPN DEBUG LOG_from_mocana():log.c:678] exchange=INFORMATIONAL msgid=2 len=96

Aug 14 17:44:42.686 [VPN DEBUG LOG_from_mocana():log.c:678] #SEND 100 bytes to 10.10.2.184[4500] (37.278)

8. Controller replies with an INFORMATIONAL-CFG_ACK, as shown below:

Aug 14 17:44:42.890 [VPN DEBUG LOG_from_mocana():log.c:678]

Aug 14 17:44:42.890 [VPN DEBUG LOG_from_mocana():log.c:678] #RECV 100 bytes from 10.10.2.184[4500] at 10.0.2.15 (37.483)

Aug 14 17:44:42.890 [VPN DEBUG LOG_from_mocana():log.c:678] spi={cb37cdce891b8db5 26f868cf9efd78ce} np=E{CP}

Aug 14 17:44:42.890 [VPN DEBUG LOG_from_mocana():log.c:678] exchange=INFORMATIONAL msgid=2 len=96

Aug 14 17:44:42.891 [VPN DEBUG LOG_from_mocana():log.c:678] I <--

Aug 14 17:44:42.891 [VPN DEBUG LOG_from_mocana():log.c:678] CFG_ACK

Aug 14 17:44:42.891 [VPN DEBUG LOG_from_mocana():log.c:678] IP4_SUBNET(192.168.1.0 /255.255.255.0)

Aug 14 17:44:42.891 [VPN DEBUG ike_cfg_response():ike_cfg.c:297] Ingoring Subnet config

Aug 14 17:44:42.891 [VPN DEBUG ike_cfg_response():ike_cfg.c:311] Recieved Acknowledgement for CFG_SET

9. In the client machine, Add an extra iIP address to one of the interfaces. And assign an ip address that is part of the subnet neing tunneled.

sudo ip addr add 192.168.1.1/24 dev eth0

10. From subnet, try reaching the internal VLAN of the controller. In the following example 172.16.31.1 is internal IP of the controller.

ping 172.16.31.1 -I 192.168.1.1

If a reply is received, setup is successful.

Setup using Virtual Machines

This section describes the prerequisites and procedure to setup using virtual machines. The following figure shows a setup using virtual machines for VIA gateway:

Figure 4 Setup using Virtual Machines for VIA Gateway

Prerequisites

Virtual Machine Host (Windows or Linux machine) for hosting at least 2 virtual machines

Two Virtual Machines

VIA-VM: Virtual machine with Linux running Ubuntu 12.04/14.04/16.04 , CentOS 6 or RHEL 6. Headless configuration (install minimal or server image)

Win-VM: Windows machine.

Controller running ArubaOS 6.5 or later

The IKEv2 configuration payload support for VIA clients (CFG_SET) feature is enabled in the controller. Refer to the ArubaOS 6.5.x User Guide for more details.

Procedure

1. In the controller, configure IKEv2 VIA profile.

2. Install two virtual machines as described in the VIA Release Notes section above.

a. Configure network such that VIA-VM has two interfaces, as shown below:

eth0: NAT or bridge to ensure internet connectivity (set to DHCP if the setup environment allows).

eth1: Internal network (no NAT or bridge) to create a private network. Set to static IP 192.168.1.1/24.

b. Configure network such that Windows-VM has one interface that has one adapter. Set the adapter to Internal network (no NAT or Bridge) with either static or dhcp ip in the range of 192.168.1.2-250 with 192.168.1.1 as default gateway.

c. Start both the VMs.

d. Ensure VIA-VM can connect to internet.

e. Ensure Win-VM can connect to the VIA-VM on both interfaces (eth1:192.168.1.1, eth0:other ip assigned by DHCP). Enable routing in VIA-VM ( sudo echo 1 > /proc/sys/net/ipv4/ip_forward). Check to see if the Win-VM can reach the eth0 address of VIA-VM. Restart VIA-VM, if needed.

3. Install VIA 3.0.0 on the Linux machine.

4. Use the VIA configuration file to install certificates and connect to VIA (see VIA Release Notes).

5. Disconnect VIA using the via-cli vpn disconnect command.

6. Set the routable networks by updating the configuration file. In the config file, set RouteEnable=Y and also set the RouteNetworks appropriately. Force load the configuration using the via-cli load config command.