I have a Balance 580 running 5.4.9 build 2573 and having trouble getting a service to forward TCP 80 to a device on the LAN.
Operating mode is NAT, no firewall rules involved, all inbound is allowed.
System is configured for HTTPS mgmt only, not HTTP.
Service is set up on both of two WAN interfaces, for any IP and TCP port 80 to forward to a server 192.168.10.10 on the LAN.
I have other services working fine with similar configuration, such as a print service running on TCP 515 forwarding to a printer.
For now, there are no real users of the network, just trying to tshoot this issue with no production traffic
I am trying to determine if the Peplink itself is responding to the port 80 requesting incoming from the WAN instead of forwarding to the LAN. I disabled HTTP for management, so it seems it should not be listening on port 80 on the WAN interfaces.
While troubleshooting, I found the hidden support page that allows packet capture, and I kicked off a capture and started investigating. However, the packet captures only worked a few short times and after I let the capture run longer I found I could no longer access the admin GUI, like the mgmt plane was hosed. It still seemed to forward traffic.
The device will get powered down this evening as the vehicle it is in is stowed, so I intend to pick back up tomorrow when hopefully the Peplink recovers after reboot.
Questions:
Is anyone aware of an issue forwarding TCP port 80 (HTTP) from a WAN link to the LAN using a service, where maybe the Peplink is intercepting and redirecting to the GUI rather than forwarding the request?
Is anyone aware of packet capture limitations in either duration or size of capture that would result in instability or nonresponsiveness of the device?
Except for the time when the packet capture hosed up the Peplink, I have not had any trouble accessing the web UI of the Peplink with HTTP or HTTPS. What I want to do is not have the Peplink be accessible via TCP port 80 from teh WAN, because I am trying to forward TCP 80 to a server on the LAN via the configured network service.
I just change in the System screen the port used for Web UI access to the Peplink from port 80 to port 8080. When I point a browser to the WAN IP that the forwarding service is enabled on, instead of the Peplink forwarding the request inside to the server on the LAN, it is sending back a web redirect to use HTTPS. The Peplink should not be listening on port 80 for administrative access after I changed the port for HTTP access to 8080. It should be forwarding the inbound port 80 request to the server on the inside.
Is this a bug?
Has anyone been able to configure a service on port 80?
Hello @knadsady,
Here are two simple ways to ensure you are not using Port 80 for administering your router(s) and that port 80 is free to use for other purposes.
Where the security is managed by InControl2
Within the InControl2 console, navigate to the devices group and under the drop down menu of Settings choose the menu of Device Web Admin Management, change your settings to:
Where the security is not managed by InControl2
Within the router web admin, navigate to the System tab and the left menu of Admin Security, change your settings to:
We do not use Incontrol. Your suggestion for disabling HTTPS on the WAN will not work for us, as these units are in mobile vehicles that are deployed to areas hit by recent catastrophic weather events. There are not technical staff local to the deployment and the only way we can administer the devices is from the WAN, so we need to keep HTTPS admin access enabled on the WAN.
The problem seems to me that for some reason, the default behavior is for the Peplink router to listen on HTTP and redirect to port 443 whenever HTTPS is enabled on the WAN. The assumption that we customers want HTTP to be redirected is not a good assumption. I would think it is common to have a Web server on the LAN that would need to be accessed from the WAN. This would require the Peplink to not redirect the HTTP received on a WAN interface but instead forward it when in NAT mode.
Is there a way to disable HTTP to HTTPS redirection?
Would you please upgrade the device using the latest firmware and test again ? Not easy to work on this with a very old 5.4.9 firmware (more than 5-6 years).
If you still found the issue for the latest firmware, please open a support ticket for support team to check.
Note: The redirection also can be done by the Web Browser, make sure you clear the cache after test on the connections.
