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:
NAT is performed by the Peplink device which has a much more powerful processor than any modem.
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.
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.
+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.
We haven’t gotten this to work. Our simplified PPPoE network diagram shows what we have.
Assuming our modem is 192.168.10.1/24. We tried configuring management network initially as 192.168.10.1/24 but like thebigbeav was redirected to webadmin for our B1. We then tried 192.168.10.2/24 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.
Believe you configured Management Network with 192.168.10.2/24 instead of 192.168.1.2/24. If my assumption is correct, you able to ping 192.168.10.2? What is the trace route result?
You’re right, 192.168.10.2/24.
Ping there goes nowhere.
PING 192.168.10.2 (192.168.10.2): 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
^C
— 192.168.10.2 ping statistics —
6 packets transmitted, 0 packets received, 100.0% packet lossTraceroute
Traceroute doesn’t get anywhere either.
traceroute to 192.168.10.2 (192.168.10.2), 64 hops max, 52 byte packets
1 * * *
2 * * *
traceroute: sendto: No route to host
3 traceroute: wrote 192.168.10.2 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote 192.168.10.2 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote 192.168.10.2 52 chars, ret=-1
*
traceroute: sendto: Host is down
4 traceroute: wrote 192.168.10.2 52 chars, ret=-1
5 * * *
traceroute: sendto: No route to host
6 traceroute: wrote 192.168.10.2 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote 192.168.10.2 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote 192.168.10.2 52 chars, ret=-1
^C
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.
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 192.168.20.1.
On our B1:
We changed the Management Network to 192.168.20.2/24.
We have an outbound firewall rule pointing to 192.168.20.1.
We have an outbound policy set to enforced for the WAN with the PPPoE modem pointing to 192.168.20.0/24 network.
On our OSX server:
We manually added a static route (route add 192.168.20.1 192.168.1.1).
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.
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?
We will look at this feature request.
