Connect to a WebUI in DMZ

I try to connect from the green zone to a WebUI (http://192.168.15.45:80) in the ORANGE Zone.
The requesting device in the GREEN zone has full access to the ORANGE zone.
But even a:

# wget --no-proxy http://192.168.15.45:80
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://192.168.15.45:444/index.cgi [following]
--2023-04-18 13:56:49--  https://192.168.15.45:444/index.cgi
Connecting to 192.168.15.45:444...

and this connection gets never established.
Wtf …? Who redirects the request? Does it the target? Why should it do this?
Before I moved this devices into the DMZ the WebUI I could access the WebUI (with an IP form the GREEN zone) Then I changed the IP to one of the ORANGE zone and reconnect the device to the ORANGE Interface.

Looking through the cgi code for the IPFire WUI I see that message occurring when IPFire thinks you are trying to access the IPFire WUI with an http access. It then permanently redirects it to https and also corrects the port to 444
You can find the code at lines 99 to 104 in header.pl

Are you sure that the IP is correct and not the same as the green0 or blue0 network interfaces.

Yes, I am sure that the address is correct!
The client has 192.168.45.15/24.
The ORANGE Interface of the IPfire is 192.168.45.5/24

As I found now, it is the same for all IP addresses in the ORANGE zone. I can use each address connected or not, and get the same result if I try to connect via wget --no-proxy
I test this from a host in the green zone that has a rule to connect all addresses in the ORANGE zone monday to friday 07:00a.m. -10:00 p.m.

Just to be sure.
Your orange network is 192.168.45.0/24,
orange interface of IPFire has address 192.168.45.5/32,
your web server in orange has address 192.168.45.15/32 ( 192.168.15.45 in the OP is a typo?).

1 Like

Yes, a typo … because I try to translate the IP addresses …

New try …
IPfire Interfaces:
GREEN0: 192.168.250.2/25 (Subnet-Mask: 255.255.255.128)
ORANGE0: 192.168.252.2/24
(Info from ip address show at the IPfire CLI)

The device in question in the ORANGE zone:
IP: 192.168.252.18/24
(that means: 192.168.252.18; Subnet-Mask: 255.255.255.0)

Firewall Rule:


Policy: Blocked

nmap from IPfire:
# nmap -Pn 192.168.252.18
Starting Nmap 7.92 ( https://nmap.org ) at 2023-04-19 09:28 CEST
Nmap scan report for 192.168.252.18
Host is up (0.011s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT STATE SERVICE
80/tcp open http
5060/tcp open sip
Looks OK. The port in question (80) is open.

nmap from mice:
mice:~> nmap -Pn 192.168.252.18
Starting Nmap 7.92 ( https://nmap.org ) at 2023-04-19 09:29 CEST
Nmap scan report for 192.168.252.18
Host is up (0.0017s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 4.87 seconds

But:
mice:~> wget --no-proxy http://192.168.252.18
--2023-04-19 09:52:02-- http://192.168.252.18/
Verbindungsaufbau zu 192.168.252.18:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 302 Moved Temporarily
Platz: /cgi-bin/index.cgi [folgend]
--2023-04-19 09:52:02-- http://192.168.252.18/cgi-bin/index.cgi
Wiederverwendung der bestehenden Verbindung zu 192.168.252.18:80.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 301 Moved Permanently
Platz: https://192.168.252.18:444/index.cgi [folgend]
--2023-04-19 09:52:02-- https://192.168.252.18:444/index.cgi
Verbindungsaufbau zu 192.168.252.18:444 …

I expect that I should be able to reach http://192.168.252.18 from mice.

Where is my fault?