Using vSZ behind NAT routers

[christoph_m_lle]

I'm about to deploy a vSZ-H in a DMZ between two firewalls, so that both APs from the internal network and from the Internet can connect to the vSZ. The network looks like this:

   Internal network
(some Ruckus APs are here)
           |
 +---------+---------+
 | Internal firewall |
 +---------+---------+
           |            \
 +-----+   |            |
 | vSZ +---+            }- DMZ network
 +-----+   |            |
           |            /
 +---------+---------+
 | External firewall |
 +---------+---------+
           |
       Internet
   (some Ruckus APs
   connect from here)

All three networks use different IPv4 address ranges, and the two firewalls perform NAT with PAT. (I can't do much about this, unfortunately.) Consequently, APs from the internal network will reach the vSZ using address A, APs connected over the Internet will use address C, and the vSZ itself has address B configured for their control interface. The firewalls will rewrite the destination address in both cases.

Will this work with vSZ-H out of the box? I'm asking because there is a Control NAT IP option in the setup routine which should be used for the "the public IP address of the NAT server on the network."

So, basically the question is: Does the vSZ communicate the configured control IP address in any of the upper layer protocols to the APs? (...which could make the above outlined setup unlikely to work)

[stephen_hall_60]

dang,  i was really hoping for some replies as i finished reading towards the bottom of your question.  I dont have a direct answer, but can offer some info.

When recently testing a new vSZ-H vm in lab-  i initally had all 3x vsz interfaces on their own subnets, ofcourse,- 246.2/24  247.2/24 248.2/24   and i had the Control NAT IP set to my Public IP (of lab).  

When trying to add APs i specficially placed behind a router doing NAT and on seperate Layer2 (again all of this is local)  I noticed those APs acting unsual- some would stay stuck in staging/discovery , some would fail at FW upgrade after moving them to a zone, others stuck at some similar early stage.   (i was giving these APs the control IP 247.2 via DHCP 43 / DNS or even  set scg ip x.x.x). 

Watching the traffic- I noticed the APs were connecting to 247.2 on 443  , *but* also trying to ssh 22 into my public IP (ie the vSZ was telling the APs use this "control nat IP" for their ssh tunnel connect-to,  and this was failing in my setup).  the APs Debug logs were showing various SSH tunnel errors.   After i changed the vSZ "control nat IP" to the same as the Control Interface's ip (247.2), everythign started working correctly.  

I also recall *soemthing* about the vSZ showing the APs IP's (and port) as the router doing the nat,   ie AP1 = 192.168.5.1:56712 , ie the vSZ was just showing this is where xyz AP is communicating with me, the vsz, from my standpoint.  (i dont have this vsz online right now to verify this)

not sure if this info helps, but it is what i noticed.  When we deploy this vsz, we plan on having the various sites connect to the vsz's network via VPNs , so from my tests so far, we will want a local IP as "control nat IP" (if any).  

(all our ruckus controllers are simply "config managers" of our APs-  ie no tunneling of data traffic, nor anything else "fancy")

im am curious about your question in terms of a zd or a vsz- do either of these controllers ever need to contact an AP directly?   
or is all controller <-> AP traffic handeled through the ssh/other tunnel the AP creates to the Controller (thus easily traversing nat s or FWs when allowed)?