So have been complaining/asking about this for years. Why, even when using a separate management interface, can we not forward ports for the wireless/public interface… and get this EVEN WHEN THE PORT ISN’T IN USE !? Port 443 for example, HTTPS isn’t even enabled, even if it was we are using a “Separate Management Interface” like I assume most people do and still can’t forward 443 for the customer on the public/wireless interface…
And, at least as of v4.4.#, you can’t even change the SSH port ? Bit of a security issue there as who in their right mind uses the default/standard SSH port ? But the end result is it’s not even possible to forward port 443 ! ? !
As far as we can tell DMZ doesn’t forward these ports and doesn’t even tell you it isn’t going to forward the ports !
You know… not sure why I even care since DMZ only works randomly and really, since port forwarding seems to randomly stop working also ( something we thought was fixed but turns out end users have just been power cycling their hardware and not calling… until they want to cancel because they are tired of constantly having to power cycle our equipment that is…) I suddenly find myself wondering why I’m even bothering to ask.
You know, if nothing else a reasonable explanation would probably at least make me less frustrated with this seemingly explainable and aggravating behavior.
Wow, 9 months and no a single response from cambium?
Brubble, fwiw you can handle this like we do, bridge or route the SM and use a real router to handle the hand off, this means not allowing hosting on your more conservative packages or provide a port translation service at your edge for your clients which is at best a hack.
Of course I am betting you have already figured out a way around this problem.
From what I know of the version of linux on the epmp line, it is very possible to forward the ports without mixing the management vlan with the client vlan but since that would mean reconfiguring the webserver (I am thinking its Lighttpd, but I havent had this confirmed) to only listen on the management vlan, this would make the SM webpage not available to clients (which as a WISP, isnt a bad thing) unless they had a switch or laptop that was able to correctly tag packets.
It is also possible, but again not implemented, to changebthe ssh port number as sshd uses a flat file and a simple cat command from the webpage would read the config file, find the current port number and replace it. Then sshd would need to restart. Again, not really a problem if sshd only listened to the management vlan which is also able to be configured.
Most of the problems with getting configuration abilities stems from the fact that the web interface uses json (java script over Network) and most of the get/post commands are just not available due to java scripts security. Really, the web interface should be http with java where needed (see dynamic information like the ealign page) and this would allow posting changes to shared config files.