I’m reaching out again because it’s been nearly two weeks since I initially posted a query on this forum, and I have yet to receive any form of acknowledgment or response from the Peplink team. As a long-time customer and supporter of Peplink products, I must say that this lack of engagement is both surprising and disappointing.
One of the reasons I’ve consistently chosen Peplink over the years is because of the company’s strong reputation for customer support and community interaction. That reputation is part of what sets Peplink apart in a competitive space. Unfortunately, this recent experience hasn’t lived up to those expectations.
I understand that teams get busy and priorities shift, but a complete silence over such a long period doesn’t reflect the high standard of responsiveness and customer care that many of us have come to associate with the brand.
I would really appreciate it if someone from the Peplink team could take a moment to review and respond to my original post. I’m hopeful this was just an oversight, and not a sign of a broader decline in forum support.
Let me check on the feature roadmap and update you the info.
The switch ports are default in untagged VLAN. Normally for the setup, we will configure the Uplink device port using untagged VLAN and this will allow the switch to connect to the network before you manage the switch using the AP Controller or IC2 management. Possible that you change the Uplink device port setting using untagged to allow the connection ?
Thanks for the suggestions so far, but unfortunately, the proposed solution doesn’t work for our setup.
The private IC2 instance used has no internet access, so the public IC2 cannot reach it. Thus the by redirection method will not work. According to the data sheet, the enterprise switches should work with private IC2—right now, that’s not the case.
If it’s not possible to roll out a full firmware update quickly, I’d suggest at least releasing a hotfix that allows us to configure a private IC2 IP as it was in the old switch firmware. This would resolve the problem until a full solution can be implemented.
I’m really concerned about the timeline here:
If firmware updates take months or even years, this device is not sustainable for production environments. Seeing how many replies this thread has shows how many people are not happy with the current situation with the switches.
It’s not just my setup that’s affected—many customers are likely in the same boat. All of us are paying massive fees to use a private IC2 instance and it’s not useable with the new switches and the old switches are not available anymore.
If this issue isn’t resolved in a timely manner, we’ll unfortunately have no choice but to explore other vendors’ solutions.
Please consider escalating this issue and addressing it as quickly as possible. We rely on these switches for critical infrastructure, and I’m confident that others would appreciate a faster solution too. Thanks!
Portion of the manual that states that a private IC2 instance should be able to manage the switches is attached:
ICVA does support the Enterprise Switch. It operates using the “By Redirection” method via IC2.
The challenge in your use case is that both the ICVA and the switch are entirely within a private network. As a result, there is currently no way to configure the switch to connect to the ICVA.
I will discuss with the team and verify if there are any other possible options. I will update you accordingly.
As we are doing feature requests here; is is possible to merge network related settings to the network tab in IC2? I find it quite weird that STP priority is somewhere far away in device managament.
A new firmware has been released, and I was wondering if there’s now a way to properly use the switch with a private InControl in an air gapped environment.
One point in the changelog mentions that the “redirect by configuration” issue has been fixed. Does that mean I can now connect to my cloud InControl once, change the InControl IP there, and then proceed to connect to an air-gapped network?
If not, is there any other way to create just a VLAN on the switch using the switch controller, without having to create an entire network on the router?
Anyone experiencing ‘lost’ wireless clients on these switches when they roam from AP to AP?Although switchports and AP’s are configured the same, sometimes a client falls into a black hole where they are still connected to the AP, but no traffic is passed. I assume that the Mac addres move when roaming is not processed by switch or AP, but have no tools to verify this.
Experienced this with Peplink and Unifi AP’s on the 48P enterprise switches. Never experienced this on the old SD switches.
Connecting all AP’s to a different brand switch solved it. Lack of viewable mac-table on the new switches makes it difficult to troubleshoot.
I’m discussing with the Engineering team, if the switch able to support the IC2 “By Configuration” to configure the ICVA settings for the Switch, will this temporary help for the issue ?
Meaning to say you need to bring the switch online in IC2 to configure the ICVA setting using “By Configuration” after that the switch will connect to ICVA.
@Jelmer_De_Jong , Support ticket is created and support team can help to verify the issue as mentioned. Ticket 25090685. You should received email from the ticketing system.
