Wireless Access

FWIW, through extensive testing I've found that a VRRP IP address cannot be used as the internal IP address of a connection profile entry...only a vlan interface IP.  We currently have 2 x 7210's in a master/standy-master configuration using VRRP to bond them.  We recently rolled out VIA to all of our users with the managment IP of the controller as the internal portion of the connection profile.  To pad in some redundancy I wanted to try change that internal IP to the VRRP address, should the master go down.  For everyone's edification this did not work.  Per TAC it SHOULD work, but it doesn't. 

Which leads me to another question....if I have 500 users in the office on my local wired network, all with VIA installed, and the master controller is rebooted, do all 500 VIA instances fire up because that local address is now unavailable, making it think it's on a public network?  Trying to nail down VIA's behavior in every possible scenario, now that it's our default VPN client.

Hi,

VIA determes network type with an attempt to connect to Internal IP address defined in the VIA connection profile. Failing this connectivity traill, the network type is termed as untrusted. 

Since the Internal IP address is not reachable in your network, VIA should establish VPN connection (if auto connect is enabled in the connection profile). In addtion to that, VIA also tries to update (or synchronize) the connection profile once it establishes VPN. It does so by connecting to Internal IP address. The VPN tunnel is also teared down if the Internal IP address cannot be reached.

Please pay attention to the following guidelines while setting up VIA connection profile.

1) The Internal IP address should be from one of the IP addresses of the Controller's interfaces. 

2) The Internal IP address should not be reachable outside the private network ( enterprise boundary). 

3) An authenticated user should be allowed HTTPS access to Internal IP address without further authentication challenges.

Changing Internal IP address is not recommened if there are existing VIA installations with already downloaded connection profiles. For such VIA clients, a change in the internal IP address is not propagated automatically.  Following are few Ideas in whcih you can try for such migrations.

1) Ensure the previous Internal IP address continues to be available till all the VIA Installation are migrated. Update the connection profile's Internal IP address and ensure the new IP address can also serve VIA connection profile refresh requests. This way existing profiles with old Internal Address can be migrated to the profiles with new Internal IP address. Once all the VIA installations are migrated to new profile ( No more requests to old Internal IP address), the old Internal IP address can be retired.

2) Instruct the users to manually clear and download a new profile.

Hope this is helpful and is what you are looking for.

Thank you Nagendra.  All of what you shared makes sense and confirmed what I've known bout VIA up to this point.  So if I'm understanding this correctly, if VIA is installed on all laptops in our environment, and if for whatever reason the internal IP address in the connection profile becomes unreachable (reboot of controller, hardware failure, etc.), VIA will simultaneously launch on all laptops and attempt an IPSEC connection to the controller through the Internet.  Correct?   

If so, is there a way to mitigate that problem?  Will putting a second entry in the connection profile stop all laptops from launching VIA, should the primary entry become available?

Hi Ryan,

if VIA is installed on all laptops in our environment, and if for whatever reason the internal IP address in the connection profile becomes unreachable (reboot of controller, hardware failure, etc.), VIA will simultaneously launch on all laptops and attempt an IPSEC connection to the controller through the Internet.  Correct?   

The changes of external IP address being not accessible are high when internal IP address is down. This is because both of these IPs are from the same controller.  Thus the via connection attempt itself fails altogher. 

And yes, if for reason only the internal IP address is not accessible, then VIA thinks it is sitting in not a trusted network and starts connection through Intranet.

But, for some reason if this happens then the connection even if established will not sustain as VIA automatically disconnect if the Internal IP address is not accessible through tunnel. 

If so, is there a way to mitigate that problem?  Will putting a second entry in the connection profile stop all laptops from launching VIA, should the primary entry become available?

Adding multiple entries in the connection profile for the field of internal IP address is not supported as of now.  

I dont see any reliable ways to prevent internal computers from attempting connection.  

You may try to restrict access to the controller's public IP from intranet.

You may try disabling auto connect feature of VIA and let users manually press the Connect button when needed.