Controller Based WLANs

Q:

How does SSL-fallback work in VIA?

VIA will initially try to establish a connection with the controller using IPsec. In some networks, the firewall may block UDP ports 4500 and 500. If a user is trying to connect where the ports are blocked, then the SSL-fallback option of VIA will kick in.

The VIA connection flow is given below when SSL-fallback is enabled:

    1. VIA will try to establish an IKE connection to the controller. 

    2. If this connection establishment fails, VIA client will turn-on SSL-fallback mode.

    3. In SSL-fallback mode, at first SSL session is established. 

    4. IKE packets are encapsulated in SSL data.

Let's take an example to understand the behavior:

We have a home user trying to connect to his corporate network using Aruba VIA and it gets a Private IP address 192.168.1.1 from his home router.

The Private IP is converted to Public IP 100.10.10.1 once the traffic hits the Home router.

Once, the user is successfully authenticated, the controller will give an inner IP address from the L2TP pool configured on the controller.

The inner IP address given is 10.10.10.1

When SSL-fallback is enabled:

1. VIA will try IKE connection with Source IP as Private IP: 192.168.1.1. 
2. The firewall is blocking port 4500 and the connection is not going through.
3. At this point, VIA will turn on SSL-fallback and establish the SSL connection. 
4. On VIA client-side, Src IP is still 192.168.1.1.
5. NAT router in between will replace the Src IP 192.168.1.1 with Public IP: 100.10.10.1
6. The controller will only see the Public IP as the VIA client IP in SSL connection phase.
7. Once this SSL connection went through, VIA will start IKE Connection. 
8. Packet on VIA client will look like:
   SSL Packet: Source IP 192.168.1.1, Destination IP: 200.20.20.1
   IKE Packet in SSL data: Source IP: 192.168.1.1 Destination IP: 200.20.20.1
9. NAT Router will convert only the SSL IP header. It will not modify the SSL data:
10. After NAT conversion or once the packet hits the Home router:
    SSL Packet: Source IP: 100.10.10.1, Destination IP: 200.20.20.1
    IKE Packet in SSL data: Src IP 192.168.1.1, Destination IP: 200.20.20.1
11. IKE packets will contain the Private IP address, assigned by the Home router.
12. So, Controller will create the user-entry for this private IP address.

On the controller we will see the following entry on the user-table:

(Controller) [MDC] #show user-table verbose

Users 
-----
IP              MAC                 Name         Role            Age(d:h:m)   Auth      VPN link     AP name Roaming Essid/Bssid/Phy Profile Forward mode Type      Host Name User Type
----------      ------------        ------       ----            ----------   ----      --------     ------- ------- --------------- ------- ------------ ----      --------- ---------

192.168.1.1     00:00:00:00:00:00                logon            00:03:00                             N/A                                   tunnel       WIRELESS                      

10.10.10.1      00:00:00:00:00:00   VIA-client   default-via-role 00:00:10    VIA-VPN    192.168.1.1   N/A                                   tunnel       WIRELESS   Aruba-VIA            

Note: As the user-table entry is created with the Private IP address provided by the Home router, we may see multiple home users getting the same Private IP address, however, the inner IP address will change to avoid any conflict.