Wireless Access

We have an Aruba650 with firmware 6.3.1.22.

Should it be possible to use Aruba VIA Client with the following setup?

Our corporate network uses a subnet of 10.1.2.0/24. The DHCP in this network is set to hand out IP’s from 10.1.2.50-10.1.2.200. The Aruba controller has a static IP in this corporate network: 10.1.2.6. Also, the controller is connected to the internet through a different network, with IP address 192.168.1.250.

We would like VIA clients for people working at home to be able to connect to the corporate network and assign them an IP in the same subnet as the corporate network, to be specific, the range: 10.1.2.11-10.1.2.30.

Is this possible? Or MUST the VIA client be assigned an IP from a different subnet than the corporate network?

The manual says the VIA-subnet has to be routeable from the corporate network. If we use the same subnet, I would assume it's routable. But that might be a wrong assumption :)

In general: what does routable mean in this case? If we were to use a different subnet for VIA clients, would it mean I'd have to tell our default gateway that it needs to route traffic to the VIA-subnet to the Aruba Controller?

A totally different question I have is about the auto-upgrade feature for the VIA client. Does this require the logged in user to have administrator rights on a Windows PC? Or will the installer run from the system account and therefor not require admin rights by the user?

The ip address your client gets is determined by a VPN pool that you setup.  If the pool that is created is on a VLAN that exists on the controller, the VPN user will be able to send and receive traffic like it is a user on that VLAN.  The controller will answer to all traffic for users that are currently on the controller in the VIA VPN user table.  If the VPN pool that is created is not routable, you will have to source-nat the traffic out of the controller or you need to create a route in your infrastructure that points to the controller ip address for the subnet that those clients are on in that pool.

"To run the downloaded VIA installer on a Microsoft Windows computer or an Apple Mac Book, the users require these access rights on the device:  For Microsoft Windows computers, the users need administrative rights for the initial installation because VIA changes the network stack in the system. Thereafter, users do not require administrative rights for connecting, downloading profiles, or upgrading VIA.  For Apple Mac Books, the users are prompted for the root password during initial VIA installation and for downloading profiles. The users are not prompted for root password for initiating a VIA connection" - http://community.arubanetworks.com/t5/Validated-Reference-Design/Virtual-Intranet-Access-VIA/ta-p/155614

Thanks, so if I setup a VPN Pool of 10.1.2.11 - 10.1.2.30, the VIA clients will be able to communicate with the rest of the 10.1.2.0-subnet through the controller (10.1.2.6).

It does seem to work fine. However, we have 1 issue:

the softphone (sip/voip) running on the VIA client computer does not seem to receive audio from the VOIP-server (10.1.2.41). It does send audio though. We notice this when making a call. The other party does hear the user on the VIA computer. But the user on the VIA computer does not hear the other party. When VIA user is connected directly to corporate network or through an Aruba RAP instead of Aruba VIA, it works fine both ways, so it's network related and not an audio setting on the via computer.

The VOIP-server is able to ping the VIA-computer, so it is routable. Firewall is disabled on the VIA-computer. The sip call (control connection) is received on the VIA computer. Only the incoming RTP (audio data) does not go through it seems. The outgoing RTP does go through.

Could it have to do with the SIP ALG setting on the Aruba Controller? Should I disable it?

I tried disabling Stateful SIP Processing, but it didn't have any effect.

Is there some way I can analyze if the traffic is blocked by the controller and why?

Here's some output that I tried:

10.1.2.41=voip-server (asterisk)

10.1.2.27=via client

(Aruba650) #show datapath session table 10.1.2.27 | include 10.1.2.41
10.1.2.41 10.1.2.27 17 5060 5060 0/0 6 24 1 1/3 1a 0 0 FCI
10.1.2.27 10.1.2.41 17 5060 5060 0/0 6 56 1 1/3 1a 0 0 FI
10.1.2.41 10.1.2.27 17 11312 4000 0/0 0 0 2 tunnel 24 1a 0 0 FY
10.1.2.41 10.1.2.27 17 11313 4001 0/0 0 0 2 tunnel 24 1a 0 0 FY
10.1.2.27 10.1.2.41 17 4000 11312 0/0 0 56 0 tunnel 24 1a 0 0 FC
10.1.2.27 10.1.2.41 17 4001 11313 0/0 0 56 1 tunnel 24 1a 0 0 FC

What stands out to me is that it seems to route 5060-traffic to "1/3" instead of "tunnel 24". Could that be causing the problem? And how do I solve it?

Update: When I use a VIA profile where split tunnel is disabled, the audio DOES work both ways and this is the output:

(Aruba650) #show datapath session table 10.1.2.27 | include 10.1.2.41
10.1.2.41 10.1.2.27 17 5060 5060 0/0 6 24 0 1/3 7 0 0 FCI
10.1.2.27 10.1.2.41 17 5060 5060 0/0 6 56 0 1/3 7 0 0 FI
10.1.2.27 10.1.2.41 17 4001 18255 0/0 0 56 0 sysmsg 107 6 0 0 FRHCV
10.1.2.27 10.1.2.41 17 4000 18254 0/0 0 56 0 vlan 215 6 0 0 FHTCV
10.1.2.41 10.1.2.27 17 18255 4001 0/0 0 0 0 sysmsg 107 6 0 0 FRHV
10.1.2.41 10.1.2.27 17 18254 4000 0/0 0 46 0 vlan 215 6 0 0 FHTV

Can anyone think of a reason why the audio wouldn't work in 1 specific direction when split tunnel is enabled? It's set to route 10.0.0.0 255.0.0.0 into the tunnel.

Update: if split tunnel is enabled and is set to tunnel everything through the tunnel (as described in http://community.arubanetworks.com/t5/Controller-Based-WLANs/How-to-tunnel-all-traffic-in-split-tunnel-mode-while-conncted/ta-p/233950 ), audio works both ways.

So in short:

with split tunnel disabled, audio works both ways.

with split tunnel enabled, and set to tunnel everything, audio works both ways.

with split tunnel enabled, and set to tunnel only 10.0.0.0/8, audio only works one way. It's strange because the VOIP-server only has 1 IP: 10.1.2.41, so I don't understand why it would make a difference. Ping and SIP-control-channel works both ways just fine as well, so it's specific to the RTP-audio.

Update: found the issue with wireshark.

The soft phone application advertises its own RTP (audio stream) ip address to the VOIP-server after the SIP setup. When doing this, it apparently sends its local wifi ip address instead of its VPN ip address. The VOIP server of course isn't able to reach that local wifi ip address, so the audio from the server does not arrive on the client.

Conclusion: the error is in the application, not in Aruba.

However, when everything is forced into the VIA tunnel, (split tunnel disabled for example..), the application does advertise its VPN ip address. So it must depend on what value the operating system returns to the application when it requests its ip address. In windows, this apparently depends on the VIA settings. I guess it would have to be researched further by a windows specialist.