Limit access to management


Hi ! Would be great to have the ability to manage the remote PEPLINK via existing PEPVPN connections from a central NOC. Today this seems impossible as all management related config is related to WAN ports ( read allowed WAN IP address and WAN Source IP ).

The only option you have is to allow all LAN networks and then you will be able to access management from all local VLANs.


If you have multiple VLANs you can restrict web admin access to a single VLAN but this then means that the WebUi can only be accessed by a device on that same VLAN (so locally connected, or remotely over a Layer 2 VPN).

Firewall rules can’t block access to the webui either or restrict access to specific subnets.

I agree, we ought to have a access control list for the local web admin ui - the ability to add a list of subnets that can access it (either locally or over PepVPN).

ACL Protection for Admin Access


I don’t understand why only a single network restriction is allowed either. How come there isn’t the option to select multiple VLANs or network interfaces to restrict the administration to? It’s all or nothing right now and that’s not good (IMHO). Just a thought.


To be fair - I suspect it reflects how most people manage their devices.

Personally I tend to use management VLANs to restrict local lan device access to the web ui on remotely deployed devices (so when I’m onsite only I can access the webui with a device in the right VLAN), then manage the entire estate using IC2 / remotte web admin. That approach (combined with IC2 managing the admin username and password centrally - and using long passwords) works perfectly for me and I suspect most others.

I had to run up test devices in my lab here to check what you wanted to achieve as I have never configured remote access (and locked it down locally) in exactly that way before using Peplink devices - which considering how long I’ve been doing this and the number of customer deployments I’ve been involved with in itself says something. Perhaps this is a reflection of differing approaches to remote web ui access between vendors.

However I agree that with a traditional NOC approach and using traditional management tools, the capability to do what you want here (locally secured webui access available over vpn) is important.

I’m sure Peplink engineering will consider improvements that could be made to enable that approach.


Thanks for that. Currently I have to open for any access on LAN. If I limit to a local VLAN I loose both snmp monitoring and management from a central place. Hope you can add it soon.


Personally I prefer a Management VLAN yes and I actually prefer to administer a router for example by console – very few devices offer this feature today and even fewer people know how to connect and operate one. :slight_smile:

I agree that the average user has a hard enough time figuring out their password to login but Pepwave is targeted towards commercial where it seems a feature like this would be very basic and expected functionality. I should be presented with a list of all available networks and interfaces and able to limit access to only a specific one OR to pick and choose, mix and match, to make an “access list” group for management.


I also post a similar topic just now.

I agreed that this should be a basic feature, for limiting access to management as protection.

A simple approach is just to allow to define an ACL in the “Allowed LAN Networks” section, even with only one LAN segment defined.


Please don’t use the term ACL as that refers to Cisco equipment and nomenclature. :slight_smile:

I’d like to see much finer-grain control capabilities for admin management as well. It seems like the most basic stuff.

Then again, my SOHOs still go belly up for any admin access locally when I enable HTTPS admin and that bug hasn’t been fixed yet either.


The Web Admin Access under System > Admin Security > Admin Settings is to limit the access from WAN, not from LAN. This is not a bug. If you wish to limit the access from LAN, please refer to the suggestion from @MartinLangmaid here.


Not to go off on too much of a tangent, but “ACL” is a generally employed TLA for “Access Control List,” not specific or limited to Cisco equipment.