SM Pings, Passes Traffic, Cannot Web Manage, Cannot SNMPWALK

I have a deployment with SM's in NAT mode, running 15.0.1 on both AP and SM's. The SM's are passing traffic for customers, so this issue is not customer-affecting.

I cannot access SM's via web interface. I cannot snmpwalk the SM's even with the correct setttings. I can ping the radios after setting NAT -> Reply to Ping on WAN Interface: Enabled

The SM's have good RF stats, and I can verify web and snmp traffic is leaving the router interface facing the AP. There is no firewall upstream of the AP's.

I can web access the AP. I can snmpwalk the AP. I can web access SM's via LUID proxy. I do not receive any response from the SM's for web or snmp connections.

I have disabled cnMaestro on the SM's even though they were not associated with any cnMaestro controller.

I cannot enable NAT -> Remote Management Interface: Enable (Use WAN Interface). This seems like the source of the problem. If I select Enable (Use WAN Interface), the page refreshes and it returns the menu to Disable. I can successfully select Disable and Enable (Standalone Config), but neither of those options gets me any joy either.

Any ideas?

Whether accessing SM Web from AP's home page  (home -> Session status) is working ?

What about if you use the LAN2 NETWORK INTERFACE CONFIGURATION (RADIO PRIVATE INTERFACE) on the AP for LUID proxy? Normally, in NAT mode, I can access the web GUI, but I can't directly communicate with sn SM using SNMP, but the LAN2 IP works for SNMP, assuming there's no different public management IP set, either manually or by RADIUS.

Yes, I can access the SM's web UI through the AP (http://AP_ADDRESS:1080). I cannot access the SM's web UI directly with its DHCP-assigned IP address. I cannot snmp query the SM directly with its DHCP-assigned IP address. I can ping the SM.

That wasn't exactly what I meant...

If you have a Canopy AP, let's say the LAN1 IP is 192.168.200.2 and the  LAN2 IP is 192.168.201.1, and you make a static route for all traffic with a destination of 192.168.201.0/24 to pass  through the gateway at 192.168.200.2, then the SM at LUID 12, for instance, would be accessible at 192.168.201.12, the SM at LUID 25, for instance, would be accessible at 192.168.201.25, and so on. That IP address should work for SNMP, as well as web GUI access.


@dshea wrote:

That wasn't exactly what I meant...

If you have a Canopy AP, let's say the LAN1 IP is 192.168.200.2 and the  LAN2 IP is 192.168.201.1, and you make a static route for all traffic with a destination of 192.168.201.0/24 to pass  through the gateway at 192.168.200.2, then the SM at LUID 12, for instance, would be accessible at 192.168.201.12, the SM at LUID 25, for instance, would be accessible at 192.168.201.25, and so on. That IP address should work for SNMP, as well as web GUI access.


@Sorry, I was responding to @subi in my prior post.

@dshea Ok, this does work as you describe. I can ping and hit port 80 on the LAN2 network with the LUID being the last octet. However, I still cannot snmp query even while using this other IP. I have tried adding the source IP for the snmp queries to the SNMP Accessing Addresses table, with no change. I again confirm traffic is leaving the router facing the AP and no return traffic is coming back in.

Separate issue, but related rant: Even if I could access with this LAN2 x.x.x.LUID IP, my complaint then would be that this method, as with any method Cambium provides that relies on LUID, is that LUID is a non-static value across reboots. This customers "IP" would change if/when the AP rebooted since likely their LUID would change as well.

Dan - Yes, that last point is very true. Those IP addresses are only valid until the AP reboots, so they are only useful temporarily.