nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

vSZ & vSZ-D Tunnel mode not broadcasting SSID

kristphr

Hello,

I have both vSZ & Data Plane instances installed. I have an issue where when enabled in tunnel mode, it stops broadcasting the SSID for some strange reason. However when I do disable the tunneling method in vSZ - the AP starts to broadcast the SSID again. I have these instances installed on a bare metal @ a colocation center.

Any ideas about what it could be? I read a post on here about doing the:

get tunnelmgr

However I'm not entirely sure what it is that I'm looking for in this output. It says on that post that the AP may not be able to see the controller when doing data plane functionality?

I'm currently running this environment in Essentials mode.

Find more posts tagged with

Accepted answers

All comments

kristphr

So after turning on the tunneling mode, I did more digging to see what has changed. And here's what I'm seeing:

------ 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@[192.168.8.10]:23233

SCG-D Subject List: [C=US, ST=CA, L=Sunnyvale, O=Ruckus Wireless Inc., E=service@ruckuswireless.com, CN=redacted]

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 connected SCG-D subject: N/A

Current connected SCG-D serial: 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:

Suggested action:

Ipsec state : IPSEC_BEGIN

Ping default gateway from last disconnection: N/A

------ 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

OK

I noticed a few things changed from previously:

------ TUNNELMGR Information ------

tunnelmgr Service:Enabled

Tunnel Establishment: Disabled

Tunnel IPSec: Disabled

Tunnel Authentication:Enabled

Tunnel Cipher:Disabled

Tunnel Cipher Key Len: 128

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:

SCG-D Subject List:

Internal Subnet:10.255.0.0

No GRE over UDP

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 connected SCG-D subject: N/A

Current connected SCG-D serial: 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:

Suggested action:

Ipsec state : IPSEC_BEGIN

Ping default gateway from last disconnection: N/A

------ 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

OK

I noticed in the first output it's trying to contact the local LAN IP @ the Datacenter. I'm assuming this could be the issue.

Also worth mentioning, I don't have an active license on file (only testing prior to buying the vDP licensing. But could that also be the issue as well? (lol)

David

Hi kristphr,

could you execute this command on the vDP?

show status

you will see if the vDP is in fact connected to the vSZ

From your screenshots the AP is not creating the WLAN tunnels for some reason, It looks like a networking issue. You need to check the networking inside the vDP infrastructure.

Thanks.

David.

eizens_putnins

SSID isn't broadcasted, because connection to vDP is not established. I am quit sure that it is some firewall or routing issue.

kristphr

@david_saez It may be a networking issue. I do have my port forwards set on the router as followed:

Image_ images_messages_616dc0cf27442d34314feb6f_964e39314fd88ae0c23b803f8b3ae597_Screenshot3_LI-2f7dc34f-7ec8-4a95-a28b-1bdb955a7be7-1375203586.jpg

The show status output:

Image_ images_messages_616dc0cf27442d34314feb6f_b58707d7dba5303e512730312b63486a_Screenshot5_LI-d1498fb5-35bf-4f85-85a9-36fc1893014d-565856960.jpg

Any ideas what it is that I may be doing wrong?

kristphr

It does show the vSZ & Data Plane are connected. And I did approve of them via the vSZ GUI.

kristphr

@eizens_putnins

I have the port forwards for this. in the above reply. Any ideas what else it could be?

vSZ: 192.168.8.7

vDP (ctrl): 192.168.8.10

vDP (mgmt): 192.168.9

is this setup not advisable? I see where a lot of the data is on an entirely separate network.

eizens_putnins

For your SSID to work, you need 2 separate things to happen:

AP must establish SSH tunnel to vSZ (for management)

AP must establish tunnel to vDP (for SSID traffic)

So what is the status of AP? Is it shown in vSZ as online? If yes, than SSH tunnel to vSz is established. I suppose, it is

But tunnel for SSID data is not established, and seems that it shows wrong IP (tunnel can't be established to internal IP, it must show routed IP). Do you have configured external IP in vDP configuration? It is neccessary same way, as external IP for vSZ.

David

Try these pings to discard a networking issue:

Inside vSZ-D CLI, ping the GW of DATA Interface using -I <DATA interface IP address> --- > ping -I 192.168.8.1
Inside AP CLI, try to ping the default GW
Inside AP CLI, try to ping GW of DATA interface. -- > ping 102.168.8.1
Inside AP CLI, try to ping DATA interface. -- > ping 192.168.8.10

kristphr

@david_saez

On the vDP, I'm able to ping the GW.

I'm on the AP CLI, however I'm connected to via the DHCP sever (on premises where the AP is) and I'm unable to ping the internal GW (remote GW where vSZ/vDP is), I can ping the NAT IP.

eizens_putnins

The first step to see what the issue is would be to make ping and trace-router from AP to external vDP address (NAT IP), and from vDP to AP (external) IP address. From your description is not clear how AP is connected to the network.

Typical multisite configuration is that both sides (vSZ + vDP) and AP are behind Firewall with NAT. Management tunnel from AP to vSZ uses different ports and different destination IP (vSZ NAT IP). It works as much as I understand.

Data tunnel need to be established from AP internal IP through firewall with NAT to external vDP address (vDP NAT IP) and it uses different port. So you need to check all route -- if local firewall permits outgoing connection on ports UDP 23233/23233, if on vSZ/vDP side firewall allows this connection in and NATs it to vDP internal IP, that default route is set properly on vDP data interface, so it can send a reply to AP and firewall allows it... You have to look on both firewalls if tunnel setup actually is initiated and if replies are sent and received.

syamantakomer

There will be 3 tunnel formed.

Controller/management tunnel between v/SZ to v/SZ-D
Controller tunnel between v/SZ - AP
Data tunnel between AP - vSZ-D

Make sure these devices can reach each other for each tunnel.

Image_ images_messages_61732522fb751956f52b3c04_95d2c5364b8a960f7c969d4b09f08cac_topology-129e5c4b-102d-458a-9fe2-7aa9c108f21e-1362391510.png

kristphr

@syamantak_omer

I'm able to ping the vSZ from the vDP. As well as from vDP to vSZ.

Doing the "Get scg" command via the AP:

------ SCG Information ------
SCG Service is enabled.
AP is managed by SCG.
State: RUN_STATE
Server List: 192.168.8.7,PUBLIC-IP
SSH tunnel connected to PUBLIC-IP
Failover List: Not found
Failover Max Retry: 2
DHCP Opt43 Code: 6
Server List from DHCP (Opt43/Opt52): Not found
SCG default URL: RuckusController
SCG config|heartbeat intervals: 30|30
SCG gwloss|serverloss timeouts: 1800|7200
Controller Cert Validation : disable

From the AP itself, these are located remotely. It shows the LAN IP 192.168.8.7 (vSZ) in the server list, but that's the LAN IP from the controller itself behind a router located at our colo.

kristphr

My server is a different IP than the NAT IP I assigned my vSZ. So do I need to remove the PUBLIC-IP of the controller above, and make that the server IP (which is my router) ?

Colo Topology:

Router <--- 123.45.6.7 - 123.45.6.11 (5 IP Block)

vSZ <---- LAN 192.168.8.7 -- (WAN)123.45.6.10

vDP <---- LAN 192.168.8.11

Port Forwards:

vSZ >> 22,443
vDP >> 23233

Remote Location:

My H510 (at a location) is pointed at the controller: 123.45.6.10

The LAN side behind my router

Image_ images_messages_6175ca0bb14ac91af59607ab_b3be7b5580cc3392237dc6b9aadc2a49_download-0650545d-b917-4d05-9745-7fcfa5b2f38d-1107943363.png

kristphr

Sorry about that, the AP is connected to a mikrotik router (basic config). With DHCP assigned for that AP.

I'll give the Mikrotik a look further on the AP's side. So when setting up the vDP's data interface, that needs to be set for an external NAT IP ?

syamantakomer

@kristphr if APs are reaching controller over the public IP then that is what you have to assign on the AP.

AP will fetch local and public both the IPs, if it can reach controller on one of them.