Perplexed - In 2026 (5) features that should be standard by now

[Lee_Zim]

As a long time Peplink owner and supporter, it is getting harder to invest in new models with these five features still not included in the lineup, when they are standard in many other platforms, including free, and built-in with the most flexible router OS - OpenWRT.

1.) Wireguard | Tailscale - this has been requested for years

2.) IPv6 - this has been requested for years

3.) SQM | QoS - this has been requested and discussed for years, yet only very limited, on the upload link; most users need it on the download link

4.) TTL option on all WAN types - this should be ubiquitous as an MTU option for all WAN connections, rather than limit to just cellular WAN

5.) vWAN Pricing - nice that now (1) vWAN is included, at a PrimeCare cost though. Adding additional vWAN’s @ $200 each - seems excessive for a simple (software) Linux switch port configuration

[DaveZ]

So I like IPv6 but … I can see lots of technical and business reasons why Peplink might be dragging their feet.

The biggest reason is that many of Peplink’s core features depend on NAT so it doesn’t really make a practical difference if LAN clients use IPv4 or IPv6, and if everything supports IPv4, then why not that?

From a programming/design perspective, having two networking stacks would vastly complicate the UI and dilute the efficiency of the processor caches and RAM.

From a business perspective, it complicates upfront and ongoing support costs because there are way more ways for things to go wrong.

But. BUT!

Ironically, the only problem-focused reason to have IPv6 support is to avoid upstream NAT.

And you know what? I’d settle for just that: IPv6 on the WAN links and IPv4 on the LAN.

[emaendel]

Can I add a 6) and a 7) to your list?
6) much better reporting on eSIM data usage. Its nice that finally more information is available in INControl (eSim Quota and eSIM expiry date ) but a very important additional number is still missing: eSim remaining data. If that number hits 0 and your Peplink happens to be on cellular backup…its down and you may not be able to bring it up without a site visit even if you replenish the eSIM plan.
7) 6 would not be necessary if there was reasonable pooled data pricing. The most basic plan is $2,000/year for 250 gigs. That makes sense for an owner of hundreds of Peplinks. But for owners of dozens its far too much. $1,000 for 125 gigs would be more palatable…

[Andrew_Williams]

For #3 cake autorate is what we’re looking for.

[Alex]

Hi everyone,

1. Wireguard is on it’s way. We are trying to put it on 8.6.0 firmware and the planned schedule is end Q2.

2. DaveZ is right. IPv6 is not a simple Yes/No answer here. We are working on something and our engineers will further elaborate what we are doing to provide transparency.

3&4. Let me check with our engineers.

5. We are reviewing the PrimeCare packages to add more value to the package.

6&7. Noted. We’ll get them implemented.

[DaveZ]

Thanks! If you’re reviewing PrimeCare plans, then please reconsider charging more for B One models with cellular. It discourages future proofing / experimentation. It also feels weird that a first-party modem is more costly to support compared to … third-party USB modems?

[georgeeo]

Given how long you have been dragging your feet on Wireguard, it SHOULD be available in a 8.5.x maintenance release - and not only on your newer 8.6 firmware releases.

[Pete]

Hi Alex,

I’m glad to hear that 1. Wireguard support might finally be coming soon. Its been long overdue.

I would just like to add 8. Improved firewall logging system. (such as including the name of the firewall rule in the log and in general a cleaner and easier to view/read logging system)

This has been requested for an extremely long time now. @Michael234 brought this up way back in 2020 and in another thread @ckirch had mentioned it was requested back in 2016. That’s 10 years now! Can you please improve the firewall logging soon?

Please include the rule name in the firewall log

The title says it all. Would be helpful.

More useful firewall logs

Peplink offers firewall rules that can be keyed off a domain name. Yippee for that. But, when such a rule is triggered to generate a log entry, the DST in the log is an IP address making the whole thing pretty useless. And, for the ninth time, please include the name of the firewall rule in the log. Those of us with many firewall rules are easily confused.

Firewall Event Log: please format as a Table

It’s very hard to read or share the firewall event log, since each entry is shown as a free-form text like this: [image] If this were in a Table form, with each data item (e.g. Action, WAN, MAC, SRC IP, Src Port, DST, LEN, TOS…) as a sepearate column, it would be so much easier to deal with.

[Lee_Zim]

@Alex - Appreciate you are reading these posts and responding to acknowledge, with potential updates in near-term firmware versions based on user feedback.

[jakub.nowicki]

My feature requests for 2026 would be:

9) VRF for Balance and improved VRF for FusionHub.
We need individual BGP and OSPF settings for each VRF is we want to seriously address enterprise and telco Customers. I need more to distribute different BGP routes to specific SF profiles with OSPF.

10) HealthCheck for Outbound Policy
Some enterprise projects require verifying if specific hosts on the other side of the VPN tunnel are reachable. If ping fails, the OBP rule should be disabled.

11) Improved eSIM settings
Peplink eSIM priority should be set to 3 by default.

[StudioTech]

I strongly agree on item number 7. I really want to add this capability to my rental fleet and sales customers but $2000 is a bit steep of a barrier to entry. A $1000 starter plan would be most appreciated. I would add it tomorrow if available.

[bryn.loftus]

I agree with comments about Firewall Logging & QoS improvements.

I also agree with VRF improvements: VRF’s through Speedfusion - Product Discussion / Feature Requests - Peplink Community

and I still firmly believe that more needs to be done with the switching range:

• Voice VLAN (LLDP-MED)
• A basic switch or two to pair with B One /smaller sites
• Later on… MLAG/MC-LAG & auto-port-configuration

[CASO.Corp]

11. Improved eSIM settings
    Peplink eSIM priority should be set to 3 by default.

I strongly agree with this.
The default setting is 1, but since Peplink eSIM is unsupported in Japan, it serves no purpose.
Furthermore, when disabling InControl2 control via WebAdmin (due to security or closed network requirements), a bug causing cellular connection to take over 15 minutes caused significant inconvenience to customers.

[Alex]

Peplink eSIM will be supported in Japan very soon. We are expanding it’s global coverage.

[Rafferty_Woentono]

Hi Pete,

I’ll bring up the firewall logging improvements with the engineering team and I believe we can get it in the next firmware update. Stay tuned.

[Steve]

Do you have a more detailed use case for 10) HealthCheck for Outbound Policy?

I’d like to better understand what the expected behavior should be when the health check fails. If ping to the target host fails and the corresponding OBP rule is disabled, should traffic matching that rule use some alternative path, or should it simply be blocked?

If the traffic would just be dropped anyway, then disabling the rule may not make much practical difference compared with leaving it enabled, since the end result would be the same.

A more specific example would help clarify the goal here, and then we can think about how this feature should be designed to solve the actual problem.

[Pete]

Hi Rafferty,

Wow, thank you so much! That would be amazing if the firewall logging could be improved in the next firmware update. Not just myself, but I know many Peplink users would really appreciate that a lot. Thank you for taking an interest in this and making it a priority. I’m really happy to hear this.

[James_Webster5240]

@jakub.nowicki

We need individual BGP and OSPF settings for each VRF is we want to seriously address enterprise and telco Customers. I need more to distribute different BGP routes to specific SF profiles with OSPF.

+++ on 9. I’ve been in several customer calls recently where the lack of VRF in peplink is a deal breaker for the customer.

ipv6 on the wan’s is also something which is being asked for a lot now, most cellular providers are now giving ipv6 public addresses which would allow for p2p speedfusion tunels.

I would also like to see speedfusion use port knocking like wireguard so wan’s can talk directly to each other even when NAT is enabled on both ends, this works great with Tailscale and other wireguard, but should be posible with peplink as it could be orchestated by incontrol.

[jakub.nowicki]

Hi @Steve,

sure, I have a few scenarios in mind. Let me anwser your question and share two examples.

If ping to the target host fails and the corresponding OBP rule is disabled, should traffic matching that rule use some alternative path, or should it simply be blocked?
OBP settings already allow us to choose what happens when “No Connections are Available”. We can either choose “Drop the traffic” or “Fall-through to the Next Rule”.
I imagine that if the ping failed, it would trigger the OBP rule to use another interface from the priority list. If all interfaces fail, the OBP would follow the previously set rule: either “drop the traffic” or “fall-through”.

Example 1
I use OBP to send all traffic (including IC2) to an L3SF VPN profile. In case of network issues behind a VPN Hub, the traffic from the remote site is still routed to L3SF, but can’t pass through devices up the route and can’t reach the Internet.

The VPN tunnel is still on, thus the OBP rule is active, but the remote site can’t reach the Internet.

This is a real-life scenario, where hundreds our Customer’s routers went offline in InControl2, because one of the network elements behind VPN hub couldn’t route traffic to IC2.

If the OBP rule on remote CPE could ping IC2 to verify the health of the interface it currently uses it would know when to switch from Interface with Priority 1 to Priority 2 (cellular).

Example 2
Our Customers use L3SF to distribute traffic from remote sites to one of a few VPN Hubs with different priorities. Like in example 1, sometimes a VPN profile is on even if other elements behind the VPN hub fail and can’t carry the traffic further. In that case, we need the remote CPEs to re-route all traffic from the primary L3SF to the secondary profile.

This issue mostly occurs when the remote traffic is routed by VPN hub from L3SF to its LAN interface (a common case in telco deployments). WAN healthcheck allows us to monitor network issues, but LAN does not.

In some cases, we can bypass those issues with BGP, but it is not always possible.

I hope what I described makes sense. I can share more details if needed

[Mark9]

#3 QoS for Bufferbloat has been promised for years by Peplink. In Peplink ticket 20050143, which was originated in May 2020 through the Peplink reseller that we deal with, the download fix was targeted for 8.2.0. Peplink missed that and postponed to 9.0.0 because performance issues were found. Your reseller relayed to us on July 28, 2022 that “Peplink has told us the following about this. This is scheduled for firmware 9.0 which is still a few months away.”

@Alex, are you able to make this happen in 2026? FYI, @wcnetworks, a different reseller, asked on Jan 25, 2026: “any updates on this? i have a bufferbloat issue on a balance 20x”. I responded “My only new thoughts these days are that Peplink should consider re-enabling Mitigate Bufferbloat for Download in the current version. They pulled Download and left only Upload because the CPU usage for Download was excessive. It cut performance about 50%. However, Peplink has far more powerful hardware in the B One than the Surf Soho where this issue surfaced, and many people would find it sufficient. After all, a good percentage of those needing fq_codel have slow internet. And someone with cable internet having Download 10 times the speed of Upload (where fq_codel or Cake is sorely needed), may be willing to have their 1Gbps Download chopped down to 500Mbps (I would).”

Note: Cake, the successor to fq_codel, was recently fixed to work on multiple CPU’s in OpenWRT, and is now capable of running at higher speeds than fq_codel with the proper hardware.