We are pleased to announce that Firmware 8.5.1 Beta 1 is now available.
Release Notes
3 Likes
Nice, a couple of things in there I will use 
1 Like
Can we expect Wireguard in 8.5.1?
3 Likes
Nice:
[Beta 1] [Remote User Access] Increased Remote
User Access user limit for PPTP , L2TP , and OpenVPN
on B One series devices to 15 users
1 Like
I have asked before, and it goes nowhere… Any chance you might fix this bug this time around?
DHCP on a WAN not working when a VLAN is set.
A WAN with DHCP and a VLAN setting, does not accept the DHCP response… and will refuse to connect up to the IP details given. The current arrangement for Pep on the WAN, is it only works with DHCP and no VLAN #. I say again… its the WAN side that needs fixing here, not the LAN.
This is the PepLink refusing to connecting with a Huawei network. NOTE: ALL my no name / cheap modems will connect with VLAN and DHCP combination on a WAN… but not the Peplink. Don’t pretend its a standards thing… If the Pep asks for a DHCP address, and receives it, then it should accept what it gets, and not squabble about its (invalid) interpretation of standards.
So can we please have this error in the Pep fixed this time?
thank you.
No issues here with DHCP and VLAN on WAN. We have several installations with a B20X or a B310-5G with exactly that setup behind a Fiber ONT.
Some ISP’s use PPPoE instead of DHCP, that also works fine combined with VLAN on WAN for Fiber ONT or bridged DSL modem.
1 Like
The issue is … The Huawei Fiber system responds with a non-tagged DHCP response, which the Peplink refuses to accept. Fine, but every other modem / network device I tried does accept the address under the same conditions.
What’s the purpose of the Pep? To be a useful network device… not a policeman.
I’ve never seen a network providing a response from a different VLAN than the one you asked for… Also have some Huawei GPON ONT’s at customer sites that give a correct response with tagged VLAN and DHCP, so works without issues on Peplink for us.
My guess is that the Peplink ignores the non tagged packets when it’s set to a VLAN. Have you tried setting the physical WAN to DHCP without VLAN and the VWAN linked to the same WAN port and also on DHCP with the correct VLAN set in there?
Not sure if it would work as a workaround.
It’s probably best to contact Peplink through a ticket to get support for this specific case.
1 Like
I wire tapped the comms and recorded the packets. Pep does the tagged DHCP request, gets a valid untagged response and ignores it, and 20 sec later, another request… repeat…
Yes, plain non tagged everything connects just fine, but this ISP has segmented its services via VLAN, and VLAN is required to get a working service.
Segmentation via VLAN is very common. For us VLAN on WAN has never been a problem, so I’m expecting the ISP’s over here (EU) are properly tagging their DHCP responses. Don’t have a site I can try a packet trace remotely on the WAN side.
It doesn’t sound logical to me to have an untagged response with a DHCP address for a tagged request. With a managed switch the packets wouldn’t be routed to the correct VLAN either.
If I don’t set the VLAN on those ISP’s you get a ‘local’ IP inside their network, which doesn’t provide internet access.
When we were our own ISP inside a shared office building some years ago. We provided all our customers with their own VLAN with Public IP and routed those tagged through the switches inside the building without issues on any router they used. This was all on a Cisco core network.
1 Like
This is ABSOLUTELY the correct response by Peplink. Getting a DHCP Offer on a different interface than the request is made on should be dropped. Otherwise you risk changing the wrong interfaces IP address. Say I’ve got two ISPs on a layer 3 switch on the WAN side, I send DHCP Request down both vlans and get two responses on vlan 1, how do I know which response belongs to which ISP? What if I get a DHCP Renew on VLAN 1 with an IP that isn’t currently assigned to either VLAN 2 or VLAN 3, which do I change?
2 Likes
I can’t agree, and I think you missed some key aspects. The multiple connection / interface ideas here are not relevant. Yes you could put a complicated mess of switches in front of the Pep, but in that case it would all be static addressing, and the Pep is not directly pinging the ISP for an address. The Pep WAN node offers one (1) only WAN setting, with one (1) only optional VLAN # per WAN port. The Pep makes a DHCP Discover/request and gets a response Offer (which it ignores here). On the WAN side, the Pep is always the client. If a current DHCP address is terminated and a new one is offered, then how is that different from a non-VLAN’d setup? Its not. The Pep will only ever have one valid DHCP assigned address on that WAN port, and only 1 VLAN #. The device connected to this WAN port is a bridged ISP modem, with thousands of connected clients, and clearly they keep everyone isolated. Now ISP modems that segment services by VLAN, do so under one IP address. I don’t see how you can have two Pep WAN ports combined into the one bridged connection.
And I say again, every dumb and cheap router I have tried under these conditions connects up and works… so why can’t my Pep do the same?
First, thank you for adding the references to special firmwares!
Second, where can I find the setting/feature that was supposedly already included in a prior release: WiFi as WAN health failure, switch to a different SSID