I’m facing some issues with my PepLink setup and would appreciate any advice or suggestions.
Setup Overview:
Router: PepLink Balance 310 Fibre 5G
Network Configuration:
LAN Network:172.16.1.1/16 subnet, covering both 172.16.1.X and 172.16.2.X
Devices on 172.16.2.X work fine with port forwarding and PepLink InTouch.
Devices on 172.16.1.X are accessible when connected to the local LAN directly but not via port forwarding or PepLink InTouch.
All devices (both ranges) can be pinged from the router’s tools menu and from other devices on the network.
What Works:
Local LAN access to devices on 172.16.1.X is functioning correctly.
Port forwarding and PepLink InTouch work for devices on 172.16.2.X.
What Doesn’t Work:
Port forwarding and PepLink InTouch fail to reach devices on 172.16.1.X.
No firewall rules blocking these connections are configured.
Steps Already Taken:
Checked NAT and Routing Configuration: Ensured there are no obvious issues, and routing between subnets seems fine as pings succeed.
PepLink InTouch Settings: Verified configuration, but the devices on 172.16.1.X are still not accessible.
Firmware: Running the latest firmware version. 8.5.0 build 5884
System Logs: Checked for any errors, but nothing apparent stood out.
Additional Notes:
Devices on 172.16.1.X can be accessed and pinged locally.
All devices respond to pings from the router and across the 172.16.1.1/16 LAN network.
Port forwarding rules are configured correctly, similar to those for 172.16.2.X.
Static routes and VLAN settings have been reviewed but seem fine.
I’m running out of ideas on what could be causing this issue. Is there something specific with PepLink’s configuration that could be blocking external access to the 172.16.1.X range? Any advice on what to check next or potential troubleshooting steps would be greatly appreciated!
Hi…
Looking at your first picture…
You have…
TCP source 2001 dst 80
tcp source 3203 dst 80
tcp source 3204 dst 80.
Are you managing the tcp source port, to be sure that port will be used by the source? Because… For any standard SO (linux,windows,etc…) the tcp source port is always a random port… (windows go one by one, ha ha ha)
For tcp source 3101 dst 443… I do the same question of tcp dst 80.
and I repeat question for tcp source 30189 dst port 3389 (eDonkey?)
So… following the standard forward port rule.
you cannot have three dst port 80 at same time… You don’t have a inbound balance device. ( Peplink have some device capable of this)
. source should be tcp any dst 80 (one rule only)
for tcp dst 443
. rule should be tcp src any dst 443
for tcp dst 3389
. rule should be tcp src any dst 3389
But… you need to check at your device… Are you getting public IP Address at your WAN?
Your service internet provider, allow you to have tcp port 80 and tcp port 443 opened?
I’m not really sure that “custom service forwarding” is what you should be using here anyway.
I would normally say to configure simple NAT port forwards it is better to define the servers + services under the “Inbound Access” sections of the configuration and remove all those custom service forwarding rules.
Service forwarding is mostly intended for when you want the Peplink to intercept and redirect traffic, as a simple example for forcing clients behind the Peplink to always use your DNS resolvers.
Inbound port forwarding should be done using the NAT rules, I wonder if this is screwing with some internal packet flow inside the Peplink with you having this configured how you do.
Thanks for the feedback on my setup! I’d like to clarify a few points and see if anyone has further advice.
My Setup:
I’m using OpenVPN to route traffic to my Peplink router. All incoming traffic is through the VPN tunnel, not directly via a public WAN IP.
I currently use Custom Service Forwarding rules to manage how specific services are routed (e.g., different source ports like 2001, 3203 for different internal devices).
Inbound Services (NAT Port Forwarding) is not an option here because I can’t select my OpenVPN connection as a WAN.
Response to Previous Feedback:
Custom Service Forwarding vs. NAT Port Forwarding:
I understand that standard NAT port forwarding is often recommended, but since my OpenVPN connection isn’t treated as a traditional WAN interface, I can’t configure it under Inbound Access. This is why I rely on Custom Service Forwarding to handle traffic within the VPN tunnel.
Source Port Configuration:
I’m aware that source ports are usually random, but my OpenVPN setup routes traffic based on specific source ports to different internal devices. This setup works for my needs within the secure tunnel, even if it’s unconventional.
Seeking Advice:
Given this setup, does anyone have suggestions on:
How to better handle port forwarding or routing with OpenVPN on a Peplink device, especially since I can’t select the OpenVPN connection in standard Inbound Services?
Any best practices or alternative configurations that might simplify or improve the current setup?
Thanks to everyone for the feedback on my port forwarding and OpenVPN setup. I managed to resolve the issue by switching from a single large /16 subnet (172.16.0.0/16) to two smaller /24 subnets (172.16.1.0/24 and 172.16.2.0/24).
I’m not entirely sure why this change fixed the problem, but splitting the network into two smaller subnets seems to have resolved any internal routing or forwarding conflicts that were causing issues. Now everything is functioning correctly with the OpenVPN tunnel, and InTouch is also working as expected.
One more thing: does anyone know if it’s possible to set up Inbound Services (NAT Port Forwarding)to work directly with an OpenVPN connection on Peplink? Any advice would be appreciated!
Glad you got it working, I wonder if this is a possible feature enhancement request for Peplink to allow the OVPN WAN interfaces to be used like a “normal” WAN in some areas of the configuration where you cannot select them - might make life simpler for these kinds of setups.
It’s possible to use the SF VPN Peer in this fashion as you can see in your port forwarding example, so hopefully it should be relatively simple for them to add the OpenVPN WAN interface to that list.
Thanks for the reply! To clarify, my Peplink router is connected as a client to my self-hosted OpenVPN server. Other devices are also connecting to this OpenVPN server via LAN or by other means.
I’m trying to set up port forwarding so that devices on the LAN of the OpenVPN server can access devices on the LAN of the Peplink router via the VPN tunnel. Essentially, I want to use inbound port forwarding over the VPN tunnel to allow traffic from the VPN server’s LAN to reach the Peplink LAN.
@admin-power2bit, you are using site-to-site OpenVPN, not OpenVPN WAN. Port Forwarding is available for OpenVPN WAN.
For the use case of site-to-site OpenVPN, the LAN subnet for both sites should be visible to each other. It looks like you need OpenVPN WAN and you may purchase the license here.
Going forward I think our operations could benefit from switching away from OpenVPN to using Peplinks InControl 2 managed SpeedFusion VPN.
The problem is that our existing remote site already use all kinds of different networking hardware that are not from Peplink.
Main goal: Establishing a scalable, secure, failsafe Site-to-Site VPN between our central office Balance 310 and existing and future remote sites (many to come), that is easily manageable and maintained without requiring network engineers.
For future sites we could deploy peplink routers.
Are there any affordable drop-in options that we can deploy in our existing sites while keeping already installed routers in place?
@admin-power2bit, you may consider using IPSec VPN if your existing routers support it. If not, connect the OpenVPN directly from the remote site clients to the central site for the time being.
Of course, Speedfusion or IPSec VPN is recommended for site-to-site VPN connection.
