Modem access / static IP configuration on PPPoE configured WAN interface


I have a Peplink Balance 30.

I feature I really miss (from pfSense) is the ability to access the modem connected to a PPPoE configured WAN interface.
My setup has multiple ADSL modems configured in bridge mode, connected to Peplink WAN interfaces configured as PPPoE.

I prefer this configuration for two reasons:

  1. NAT is performed by the Peplink device which has a much more powerful processor than any modem.
  2. All configuration is contained in the one place and if a modem fails, it’s a simple matter of configuring it for bridge mode and it’s a drop in replacement.

In the past, using pfSense, I was able to assign a PPPoE connection and configure a static IP address on the same physical interface. In fact it is even possible to use DHCP but in the case of pfSense, it would add the modems IP address to the list of DNS servers which is not what you want. Using DHCP in the scenario (with PPPoE) is also not advisable as modems often use the same private IP subnet, therefore multiple WAN interfaces on the Peplink would be on the same subnet.

So that’s my feature request; allow configuration of a static IP address on a WAN interface configured as PPPoE and route accordingly from/to LAN.

Simple :slight_smile:

And thanks guys! Peplink devices are awesome!


Hi Nic,

Thanks for using Peplink!

If I understand correctly, the purpose of the IP address is for managing the ADSL modem. Right? I think it is a good idea. We will incorporate this feature in our future firmware.


Thanks Nic, glad to know you are enjoying it :wink: We will look at this feature request.

Hi Michael,

Yes exactly. Stupidly, I didn’t search the forums on this topic first but here is another post on the same issue:

So +1 for this feature request!


+1 for this feature, as it is not available in firmware 5.4.9 build 1564.

We do not only need modem access, but also would like to run a watchdog/health check for the modem (periodic ping) on a static IP.

We can’t use the public IP assigned to the router because DDNS updating is unreliable. In our case it really broke our setup after DDNS wasn’t able to update the new IP address, the watch dog was still polling the old IP, resulting in random DSL modem power cycles. Every time the old IP - which was now assigned to another customer of our provider - was unreachable our Zyxel VDSL was being power cycled: not desired.

This is definitely a feature request that our Engineering Team is still planning to implement via a future firmware update. Once the team gets close to release, we will be sure to announce it to everyone.

Still waiting for this feature.

Hi, has this been added yet? it would be a useful feature to get to a modem in front of the PPPoE connection to see a DSL sync rate etc.

Hi all,

We target to support this in v6.2.1.

Is this available in 6.2.1?

If so, how does one access?


Please find the attached screenshot below.


We haven’t gotten this to work. Our simplified PPPoE network diagram shows what we have.

Assuming our modem is We tried configuring management network initially as but like thebigbeav was redirected to webadmin for our B1. We then tried and go nowhere. We had success with our non-PPPoE modem using a static route defined using route command (and no management network) but the PPPoE modem we can’t seem to get it thru yet (with or without a static route either). We must be doing something else wrong. Firewall, outbound, ???Appreciate your insights.


Hi Voltar,

Believe you configured Management Network with instead of If my assumption is correct, you able to ping What is the trace route result?

You’re right,
Ping there goes nowhere.
PING ( 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
— ping statistics —
6 packets transmitted, 0 packets received, 100.0% packet lossTraceroute
Traceroute doesn’t get anywhere either.
traceroute to (, 64 hops max, 52 byte packets
1 * * *
2 * * *
traceroute: sendto: No route to host
3 traceroute: wrote 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote 52 chars, ret=-1
traceroute: sendto: Host is down
4 traceroute: wrote 52 chars, ret=-1

5 * * *
traceroute: sendto: No route to host
6 traceroute: wrote 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote 52 chars, ret=-1

I am having exactly the same symptoms as voltar.

Peplink support, why dont you document this clearly and accurately? Is the IP address for the management interface purely arbitary, or does it have to be the IP address of the DSL modem? You are making this harder than necessary.

Steve Chandler


After looking everywhere for what was preventing success we believe we found an address conflict.
On our PPPoE modem:
We changed the modem address to
On our B1:
We changed the Management Network to
We have an outbound firewall rule pointing to
We have an outbound policy set to enforced for the WAN with the PPPoE modem pointing to network.
On our OSX server:
We manually added a static route (route add

We may not need all these but we at least have it working now. If we find we don’t need some of the above, we will update our reply accordingly.
BTW, it turns out original address for the modem was directed to a wireless AP (oops). Sorry for the confusion.


1 Like

Hi Voltar,

Outbound firewall and policy are not needed if you are using default settings. Thanks for sharing! :up:


Confirmed that we do not need outbound firewall rule and outbound policy for access to PPPoE modem, just the management network setting and, of course, a non conflicted address! We do need the static route on our internal server pointing this PPPoE address to the B1 for this to work from within our LAN.


Thanks very much voltar! That worked for me too. Much appreciated.

If Peplink had documented this properly it would have saved us all a lot of time. Peplink how about putting something in the knowledge base to stop future users going through this?


Hi Steve,

Thanks for suggestion. Will do.