Ruckus vSZ-D Tunneling

Ruckus Virtual Smart Zone – Data plane (vSZ-D) works with vSZ-H or vSZ-E and provides data plane services and tunneled WLANs. In simple terms if we want all the WLAN traffic from a remote/branch location tunneled back to the data center instead of locally switched we would need to deploy Ruckus vSZ-D and integrate is with vSZ-H or vSZ-E. It is important to know that vSZ-H and vSZ-E alone will not be able to accomplish this without vSZ-D.

Installing and integrating vSZ-H, vSZ-E and vSZ-D is not very difficult and I was able to accomplish that with ease. However, getting the tunneling to work required some extra effort. After reading bunch of documentation, blogs and forum posts I was able to successfully get it working. Following link has some good information on how to install vSZ-H, vSZ-E and vSZ-D.

I used the following topology in my lab to test out the tunneling configuration.

vSZ-D Tunneling – Topology

After installing vSZ-D before powering it on there are couple of key steps that are needed. Here is a quick “Networking” overview of the ESX environment. vSZ-D will have a management/control interface and data interface (NOTE: Data interface VLAN must be separate from the WLAN user VLAN).

ESX – Networking

From the networking and under vSwitch2 (Data-Interface), I needed to make changes to the vSwitch and Data-Interface as follows:

  • vSwitch – Edit – Security – Promiscuous Mode (Accept)
  • Data-Interface – Edit – General – VLAN ID – All (4095)

Once this was complete I powered on the vSZ-D VM and went through the setup process described here. I did make a mistake of not assigning VLANs and IP’s properly when I first installed it which you will not have to worry about if you go through the proper install. Instead of reinstalling it I was able to use the CLI to fix the NAT IP and Data interface IP:

config
!
### Since my APs and vSZ-D are sitting behind their own firewalls ###
### NAT is needed so that APs can reach the vSZ-D ###
### Port used for this is 23233 ###
ip data-nat 172.16.1.125 23233
!
interface data
!
### Assign static IP/Mask/Gateway ###
ip address 10.101.32.11 255.255.255.0 10.101.32.1
vSZ-D – Show Interface

Firewall Configuration

Depending on the firewall changes will need to be made for all this to work. In my topology APs and vSZ’s were both behind NAT devices with no connectivity between them. This requires setting up NAT in the firewall. As show earlier 172.16.1.125 is the Public IP in my test scenario following commands were used on the Cisco ASA to get the NAT working for vSZ-H and vSZ-D with a single IP.

object network host-10.101.0.132
 host 10.101.0.132
!
object network host-172.16.1.125
 host 172.16.1.125
!
object service udp-23233
 service udp source eq 23233 
object service tcp-23233
 service tcp source eq 23233 
!
object network host-10.101.32.11
 host 10.101.32.11
!
access-list dmz-in line 99 extended permit tcp any host 10.101.0.132 eq 8443
access-list dmz-in line 99 extended permit tcp any host 10.101.0.132 eq ssh
access-list dmz-in line 99 extended permit tcp any host 10.101.0.132 eq 443
access-list dmz-in line 99 extended permit tcp any host 10.101.0.132 eq 123
access-list dmz-in line 99 extended permit tcp any host 10.101.0.132 eq 80
!
access-list dmz-in extended permit udp any host 10.101.32.11 eq 23233 
access-list dmz-in extended permit tcp any host 10.101.32.11 eq 23233 
!
### When using port NAT order is important ###
### Since I had a single IP available I redirected ###
### Few ports to the vSZ-D server ###
nat (dmz,outside) source static host-10.101.32.11 host-172.16.1.125 service udp-23233 udp-23233
nat (dmz,outside) source static host-10.101.32.11 host-172.16.1.125 service tcp-23233 tcp-23233
### THIS LINE IS FOR vSZ-H ###
nat (dmz,outside) source static host-10.101.0.132 host-172.16.1.125 (this will get processed last)

After all this was setup and I logged into the access point and ran, “get tunnelmgr”. Looking under the “Run Time Status”, I noticed that there was no tunnel ID, nor it was showing connected. This was due to a minor issue with my NAT configuration, however, I wanted to show what a non working tunnel looked like.

AP Tunnel – Non Working

------ TUNNELMGR Information -----
 tunnelmgr Service:      Enabled
 Tunnel Establishment:   Enabled
 Tunnel IPSec:           Disabled
 Tunnel Authentication:  Enabled
 Tunnel Cipher:          Disabled
 Tunnel Cipher Key Len: 
 Tunnel Forward Bcast:   Disabled
 PMTU:                   Auto
 PMTU Discovery:         Enabled
 Node Affinity:          Disabled
 Force Fragmentation:    Disabled
 Offload:                Disabled
 Tunnel Type: Ruckus-GRE
 SCG-D IP List:       =1@[10.101.32.11]:23233
 SCG-D Subject List:       [C=US, ST=CA, L=Sunnyvale, O=Ruckus Wireless Inc., E=service@ruckuswireless.com, CN=]
 Internal Subnet:    10.255.0.0
 GRE over UDP: AP/SCG-D UDP port # 23233/23233
 Keep Alive Interval/Retry-limit: 10/6
 Keep Alive Interval2: N/A
 Keep Alive Count: N/A
 Force Primary Interval: N/A
 ------- Run Time Status (Debug) -------
 Current tunnel ID: N/A
 Current failover mode: 0
 Current connected SCG-D: N/A
 Current Session UpTime: N/A
 Current Keep Alive retry count: N/A
 Number of tunnel (re)establishment: 0
 FIPS mode: Disable
 Reason on last re-establishment: can't connect to SCG-D
 Suggested action: check connectivity between AP and SCG-D
 Ipsec state : IPSEC_BEGIN
 Ping default gateway from last disconnection:
 Tue Mar 31 16:00:10 UTC 2020 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: seq=0 ttl=64 time=0.544 ms 64 bytes from 10.0.0.1: seq=1 ttl=64 time=0.432 ms --- 10.0.0.1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.432/0.488/0.544 ms PING 10.101.32.11 (10.101.32.11): 56 data bytes --- 10.101.32.11 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss
 ------ Logging parameters ------
 Log Console:  Disable
 Log Level:  3
 ----------- gre1 status -----------
 gre1: RX packets N/A errors:N/A dropped:N/A
 gre1: TX packets N/A errors:N/A dropped:N/A

Once I fixed the minor issue with the NAT tunnel was established successfully. Looking at the same stats under “Run Time Status”, I was able to see the Tunnel ID, Connection and Session time.

AP Tunnel – Working

 ------ TUNNELMGR Information ------
 tunnelmgr Service:      Enabled
 Tunnel Establishment:   Enabled
 Tunnel IPSec:           Disabled
 Tunnel Authentication:  Enabled
 Tunnel Cipher:          Disabled
 Tunnel Cipher Key Len: 
 Tunnel Forward Bcast:   Disabled
 PMTU:                   Auto
 PMTU Discovery:         Enabled
 Node Affinity:          Disabled
 Force Fragmentation:    Disabled
 Offload:                Disabled
 Tunnel Type: Ruckus-GRE
 SCG-D IP List:       =1@[172.16.1.125]:23233,[10.101.32.11]:23233
 SCG-D Subject List:       [C=US, ST=CA, L=Sunnyvale, O=Ruckus Wireless Inc., E=service@ruckuswireless.com, CN=
 GRE over UDP: AP/SCG-D UDP port # 23233/23233
 Keep Alive Interval/Retry-limit: 10/6
 Keep Alive Interval2: N/A
 Keep Alive Count: N/A
 Force Primary Interval: N/A
 ------- Run Time Status (Debug) -------
 Current tunnel ID: 20
 Current failover mode: 0
 Current connected SCG-D: [172.16.1.125]:23233
 Current Session UpTime: 4 mins 10 secs
 Current Keep Alive retry:0  sent:25  lost: 0
 Keep Alive Average Round Trip Time: 0.018984 seconds
 Number of tunnel (re)establishment: 2
 FIPS mode: Disable
 Reason on last re-establishment: can't connect to SCG-D
 Suggested action: check connectivity between AP and SCG-D
 Ipsec state : IPSEC_BEGIN
 Ping default gateway from last disconnection:
 Tue Mar 31 17:58:37 UTC 2020 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: seq=0 ttl=64 time=1.232 ms 64 bytes from 10.0.0.1: seq=1 ttl=64 time=0.384 ms --- 10.0.0.1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.384/0.808/1.232 ms PING 10.101.32.11 (10.101.32.11): 56 data bytes --- 10.101.32.11 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss
 ------ Logging parameters ------
 Log Console:  Disable
 Log Level:  3
 ----------- gre1 status -----------
 gre1: RX packets 53 errors:0 dropped:0
 gre1: TX packets 28 errors:0 dropped:0
 gre1: RX idle time: 0.702893 seconds
 OK

NOTE: Another important thing to note here is that until the vSZ-D integration with vSZ-H is complete and this tunnel is showing up, access points will not broadcast the tunneled SSIDs. Looking at Access Points –> General section, nothing will show up under WLANs.

Creating a Tunneled SSID

Creating a tunneled SSID is a very simple and straightforward process. Only difference is that, when creating a new WLAN SSID, under “Data Plane Options” enable “Tunnel WLAN traffic through Ruckus GRE”. Next under “Advanced Options” specify the VLAN ID that exists in the corporate or DC.

Once the SSID was broadcasting I was able to successfully connect to it and my device acquired an IP from VLAN30 at the corp.

vSZ-D – Client connected to a tunneled SSID

I would like to give credit to the following sites and links. I recommend reading these links to further understand the whole process:

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

WordPress SEO