The Industrial Raspberry Pi Forum

Hello

we have 9 Kunbus RevolutionPi Connect+ 32 GB modules and 1 Kunbus RevolutionPi Flat module mounted on a customer internal module specific local network. Our server communicates with the modules through a VPN tunnel between the server's virtual network and the customer local network. According to the customer's IT department does the firewall rules allow traffic to TCP port 80 from all IP addresses on the virtual local network to all IP addresses on the customer local network. We have no problems with accessing the configuration web server on 4 Connect+ modules and the Flat module all running the Stretch based distribution mounted to the network. We can't connect to 5 Connect+ modules running the Buster based distribution. We prepared the 5 newer modules on our office local network network without any perceivable problems. We can't connect to the configuration web server on these 5 modules from the server. According to the firewall logs from our customer's IP department does the web server on TCP port 80 redirect the connection to TCP port 41080. TCP port 41080 is of course not open in the customer firewalls.

Does the admin web server on the Buster based distribution redirect the web clients to TCP port 41080? Is this a difference between the Stretch and Buster based distributions? If this is a difference when was the default web port changed to TCP 41080?

With regards,
/m-o r

Hello,

the port 41080 is for PiCtory web-site, when you are using the Buster Image. So you cannot connect your devices with the web-server you are using with this port, because it is already ocupated by PiCtory.

BR, Julian, Kunbus Sales Team

Why is the Buster image web server on the standard port 80 then redirecting the client to port 41080 according to the IT department at our customer? The admin web server on the Stretch image does not redirect in the same way. A module based on Buster can't be reached by a web client through the VPN tunnel which currently only allows ICMP, TCP port 80 and TCP port 9000. We have requested that the customer firewall also allows TCP port 9001 and TCP port 41080.

Every time a web browser on our server attempt to connect to the admin web site on any of the 5 modules based on Buster it times out with the :41080 added to the URL in the address bar. On our local network at the main office does the web browsers have no issues with connecting to the admin web page.

We have tried Microsoft Internet Explorer, Microsoft Edge Chromium and Google Chrome on the server without any difference when attempting to connect to the 5 Buster modules.

Dear Mats-Olov,

It does indeed redirect. The IT guys at your customer site are right. So you options are:

1) On the firewalls of your VPN, open port 41080 too. This is the path you chose and It is a good one. Some IT departments may be reluctant to comply, though.
2) Reconfigure the web server running on the revolution pi on port 80 to act as a proxy for pictory, so you only need port 80.
3) On the firewalls of your VPN, open port 22 and SSH into the Revolution Pi, then use SSH port forwarding (this is what I do, because I can forward however many ports I like and not have to bother IT for small things like this).

I also don't know why this change was made, since I don't work for Kunbus.

Kees Jan

Hi Mats-Olov,

the behavior was changed with the Buster Image. It is described in our release notes (https://revolutionpi.com/tutorials/rele ... rect=en_US):

[...] Also, PiCtory is now configured to port 41080 by default. HTTP requests on port 80 are now forwarded to port 41080 per redirect rule. If your project requires port 80, you can use Apache”s rewrite rules accordingly to call PiCtory, or simply remove the redirect rules and include the port in the URL to reach PiCtory.

If order to restore the stretch behavior you can remove the forward and change the port from 41080 to 80 if needed.

Nicolai

We successfully persuaded our customer's IT department to also open TCP port 41080 in addition to TCP port 80. I was a bit nervous since my supervisor isn't fond of any additional changes that have to be made to our logger platforms (Kunbus RevPi Connect+ and Flat) to be able to deploy them because of the added complexity and administrative overhead. I will read future release notes for Kunbus firmware more closely.

Hi, I have very similar problem, using CoreSE, I have a dashboard running on it in the kiosk mode, using HDMI.
chromium-browser was working fine, but now it is saying about the private adress not secure, I have to use mouse and click in to pass that error, then everything works as intended. BUT the user wil have no mouse or keyboard. How can I get rid of the secure port forwarding completely? I will run the dashboard in localhost only and with no ethernet/wifi enabled.
If I will run in HTTP only mode, will be fine
Regards
Olda