Managing Mobility Express across subnets?

[mcreilly]

Is there some limitation in Mobility Express that denies access to the admin web interface from a different subnet? I'm drawing a blank with the documentation unfortuantely.

I bought three 1815 APs, one with the -C suffix to use as the controller, for a community centre I look after. They're connected via a 2960L switch then an 877 ISR to an ISP. I have a matching 877 at home and have a simple VPN tunnel established between the two routers. Home network is 192.168.1.0/24, remote site is 172.16.1.0/24. Pretty sure the VPN isn't at fault as I can browse the management interface of a printer and a building management system on the remote subnet from my Mac at home with no problem - and I can also SSH into the CLI on the embedded WLC with no trouble.

If I plug in a laptop on the 172.16.1.0 network over at the community centre I can access the WLC web interface no problem, but it just doesn't work from home across the VPN. I get a certificate error (so there's some connectivity there) but then nothing... other than eventually a page time-out. It's not browser or machine specific (same happens from Mac and PC with Chrome, Firefox, Safari and IE).

I have quite a few years experience with standard (and virtual) WLC setups so I wasn't expecting too much trouble getting this little Mobility Express solution set up, but this has me scratching my head. Is it some deliberate limitation in the low-cost solution? Some security setting I need to over-ride (I've browsed all the menus and can't find anything relevant).

I'm waiting for my reseller to properly register the SmartNet I bought for both the APs and router so a call to TAC (if needed) will have to wait a few days. Anybody have suggestions for now? Thanks in advance!

[Some_Guy]

This sounds very similar to a head-scratcher I have at a site with some 1815i APs. The web interface negotiates the TLS session successfully (as long as browser accepts the self-signed certificate), but then when time comes for the HTTP content, it just closes the TCP socket. I've never been on-site so I don't know if it works from there.

Only the one site with 1815i APs does this for me. Web interface works fine for my ME deployments at all other sites, which are on 2800 APs. Never been clear why. I've always just assumed it must be some limitation specific to the 1815i since it is a "cheap" low-end machine compared to the 2800s.

Like you I am familiar with the traditional and virtual WLCs, so personally I find ME's toy web interface totally useless anyway. SSH and Prime Infrastructure are what I use to manage.

If you do end up taking this to TAC I would be curious to know what's going on here.

[patoberli]

That should work.
I assume your wireless is not using the IP range 172.16.1.0/24?
If you use the same IP range on wireless and wired, you probably need to enable the option to manage the AP via wireless.
Which software are you running on the ME?

[mcreilly]

I think it's 8.5.143 as it shipped, I'll upgrade to latest this afternoon (couldn't until now presumably because SmartNet hadn't yet been registered, and it has now).

[mcreilly]

Just checked and it's 8.5.131 so a little earlier.

[mcreilly]

I updated to 8.8.120.0 - latest apart from an 8.9 release which has notes saying only recommended if you're using a particular model switch which I don't have. No difference. Will open a TAC case now.

[Adam Lewis]

Did you find out why you couldn't access the web GUI from a different subnet?

[mcreilly]

Unfortunately not - that remains a mystery. That was on a different deployment though, not the one at home. It's most peculiar, I can SSH to the remote controller just fine and I can ping it, so connectivity over the VPN to the remote site is OK, but using the same laptop and browser that I can access the GUI with locally on the same subnet it just will not load the page remotely. I can access web interfaces of other things on the same subnet as the WLC (the printer in the office for example) without a problem, only the WLC fails.

[patoberli]

Sounds like a missing route/default gateway for the management interface.

[mcreilly]

If the route or default gateway was missing or wrong, surely I wouldn't be able to ssh to the command line on the unit, which works just fine?

Just double checked with "show interface detailed management" from the CLI. The IP, mask and gateway are definitely correct.

From the same machine here, "ssh -l admin 172.16.1.11" works perfectly. Browsing https://172.16.1.11 - browser says "transferring data from 172.16.1.11"... and then... nothing.

The same machine and browser can be used without a problem to manage my home Mobility Express controller via both ssh and https, the only obvious difference being they are on the same subnet (192.168.1.0/24).

[patoberli]

You are right, missed the part about SSH.
There might be a firewall either locally configured or on another device in the path, blocking the webinterface access.

[mcreilly]

Definitely no firewalls in the path - I configured everything myself. Couldn't be a lot simpler, just two routers with a point to point VPN between them.

Mac - 2960 switch - 887 router - internet - 887 router - 2960 switch - 1815 AP

[Adam Lewis]

@mcreilly  My issue is identical to yours.  I have many 5508 and 3504 controllers that I can access via the web through our DMVPN network, however the ME 3802 I cannot do this.

Like you I can ping and SSH to it, but when loading https it says transferring data and just stays on a blank page.  If I am on the local subnet with the ME WLC I can web into it without any issues.  

I have tried enabling non secure web, enabled management via wireless, but no change.  I am out of the office today and next week, but plan on opening a TAC case once I return and I will update this thread with the findings.  I also had my wireless SE to a TAC case search for this issue which came up with nothing.  So we shall see.  BTW I am running image 8.5.161.  

[mcreilly]

Thanks Adam. Good (sort of!) to know that the problem isn't just on my deployment. Will be interested to hear what TAC come up with.