Our environment uses RADIUS to push VLAN and IP address to SMs when they connect. Normally we just do bridging.
I want to create a consistent experience for our technicians when they're working on an SM where the SM's management interface is always available at the default IP address 169.254.1.1, whether the SM is new out of the box, linked via ICC, or provisioned to a special 'service mode' to allow access. To do this last part I've created a special VLAN profile and want to use NAT.
This special VLAN profile pushes two VLAN IDs, one for management, and one for untagged ingress. The Management IP is pushed via RADIUS. The untagged ingress VLAN becomes the NAT WAN interface and has DHCP on it.
With NAT and Remote Configuration Interface enabled, NAT WAN successfull gets an IP address via DHCP, RCI keeps the RADIUS-assigned address, and I can ping the SM via 169.254.1.1. Access *through* the SM works fine, I can surf the 'net and so on. I can also access the RCI address from behind the SM.
What does not work is accessing the NAT LAN IP directly. This works until the SM links to the AP. I am not sure if this is specifically associated with RADIUS, as the last time I tried accessing an SM's management interface from the LAN IP while it was in NAT mode was on version 13 software.
I have tried 15.1 and 16.0.0.1, I can't find any knobs that would change this behaviour.
Any advice is appreciated. I am trying to avoid forcing our technicians to use an external tool to determine the SM's external IP address.
It has been many years since we tried to do something similar.
When using VLANs and the SM in NAT mode, the SM can only be accessed from the ethernet using the management VLAN. What is somewhat incoherent, because the LAN part (ethernet) should not be subject to VLANs when in NAT mode.
In its day, I already had a discussion on this issue with Motorola (it was not yet Cambium) and on the logic of how NAT mode should work with VLANs.
For this same reason, we abandoned the option to use VLANs.
Ideally, the ethernet part (LAN) should be independent of VLANs. And for security restrictions, allow or deny access to web management with a specific opcion.
Ideally, the ethernet part (LAN) should be independent of VLANs. And for security restrictions, allow or deny access to web management with a specific opcion.
It seems this has finally been fixed!!! I found an option under the IP Configuration tab, "Default Alternative LAN1 IP address". I suspect the intent of this option is to always make 169.254.1.1 available if you specify a different address above, but I found that it has the effect of making 169.254.1.1 available regardless of anything else you do in the configuration.
Presently I have the following options set: IP Default Alternative LAN1 IP address: Enabled NAT
RADIUS is pushing a VLAN profile where the untagged ingress VID is the same as the SM's management VID, and an IP address.
The IP address from RADIUS is assigned to the RCI/RMI as you would expect when the SM is bridging, including downloading its Zero-Touch config file and communication with cnMaestro. (Note that the other settings for the Remote Management Interface either ignore it, or assign it internally but are unusable.) The NAT IP stack sends a DHCP request on the untagged/management VLAN and obtains its own IP. This functions mostly as expected: The device sitting behind NAT can access anything on the management VLAN or further (including other SMs if you have isolation disabled), but it cannot access the RCI/RMI address of the SM. And of course, you can access the SM via 169.254.1.1 the entire time!
The RCI/RMI remaining working is very good news to me, as our goal is to have our installers do almost all provisioning/configuration through an app that runs on their smartphones. A simple reboot of the SM is all that's required to get a new config that will disable NAT and change it onto a production VLAN.
I have tested this with both the default VID (1) and a custom VID. I have not tried addresses other than 169.254.1.1. Based on the wording I think that's all we get. Lucky for me it's exactly what I want.