1
Zenarmor (Sensei) / Re: Web interface not accessible after installing Zenarmor
« on: November 20, 2022, 05:34:05 pm »
My fault, I had to disable Hardware CRC and Hardware TSO under Interfaces->Settings.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
Zenarmor (Sensei) / Web interface not accessible after installing Zenarmor
« on: November 20, 2022, 05:28:13 pm »
Hi all!
I've just installed Zenarmor, free edition, following the manual and selecting the LAN interface and didn't changed any option.
After that I cannot access the web interface or SSH anymore. I can still reach the web-interface by using the VPN to access to the LAN from outside.
Did I missed something? What should I do to fix this?
Note: I've installed on an PC Engines Apu2 with 4 GB ram.
I've just installed Zenarmor, free edition, following the manual and selecting the LAN interface and didn't changed any option.
After that I cannot access the web interface or SSH anymore. I can still reach the web-interface by using the VPN to access to the LAN from outside.
Did I missed something? What should I do to fix this?
Note: I've installed on an PC Engines Apu2 with 4 GB ram.
3
20.7 Legacy Series / Re: [FIXED] Web-gui not accessible after last upgrade
« on: February 17, 2021, 10:44:18 am »Any update on this by any chance?
Honestly for now I am running the interface as http on another port because I hadn't the time to further investigate on this. I have also upgrade the system to release 21.1.
4
20.7 Legacy Series / [FIXED] Web-gui not accessible after last upgrade
« on: January 08, 2021, 02:35:53 pm »
Hi all!
Today I have updated the system as usual from the web-gui.
The firewall was updated not so much time ago, so I think it was just a minor upgrade.
After some time I found that I was not able to access the web-gui. So, I rebooted it using ssh.
This didn't fixed the issue. The system is running 20.7.7_1.
I tried /usr/local/etc/rc.restart_webgui and checked that lighthttpd is running:
And php-fpm:
Checking file permissions:
Any idea?
edit: this is the firewall log obtained from the shell (while accessing to the web gui from a client). It does not seems that there is any rule blocking it:
Log while accessing to the web-gui from the router itself:
EDIT 2:
I have changed the port assigned to the web-gui under /conf/config.xml , thinking that perhaps a firewall rule could block it, but that din't helped in any way.
But after this change, accessing from the shell of the firewall the output changed from "connection timeout" to
So, I tried to disable https and the output changed again:
The web-gui is still not accessible from clients, but seems anyway an improvement on fixing this issue.
EDIT 3:
I tried unplugging the two WAN cables, and in this way the web-interface was accessible again. So it seems like some fw rules that were not applied. Applying the update of the firewall also reloaded the rules, and so I got cut-off from the web-gui.
I still need to better investigate on it but at least now I can access the web-gui and better investigate on the issue.
Today I have updated the system as usual from the web-gui.
The firewall was updated not so much time ago, so I think it was just a minor upgrade.
After some time I found that I was not able to access the web-gui. So, I rebooted it using ssh.
This didn't fixed the issue. The system is running 20.7.7_1.
I tried /usr/local/etc/rc.restart_webgui and checked that lighthttpd is running:
Code: [Select]
root@OPNsense:~ # ps aux | grep light
root 88505 0.0 0.2 18224 7472 - S 14:19 0:00.10 /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf
Looking at lighthttpd logs (nothing important as those logs are very old):Code: [Select]
Sep 24 16:10:38 OPNsense lighttpd[97861]: (gw_backend.c.315) gw-server re-enabled: unix:/tmp/php-fastcgi.socket-1 0 /tmp/php-fastcgi.socket
Sep 24 16:10:39 OPNsense lighttpd[97861]: (gw_backend.c.236) establishing connection failed: Connection refused socket: unix:/tmp/php-fastcgi.socket-1
Sep 24 16:10:41 OPNsense lighttpd[97861]: (gw_backend.c.315) gw-server re-enabled: unix:/tmp/php-fastcgi.socket-1 And php-fpm:
Code: [Select]
root@OPNsense:~ # tail /var/log/php-fpm.log
[10-Dec-2020 17:45:46] NOTICE: configuration file /usr/local/etc/php-fpm.conf test is successful
[10-Dec-2020 17:45:47] NOTICE: fpm is running, pid 26438
[10-Dec-2020 17:45:47] NOTICE: ready to handle connections
[08-Jan-2021 13:46:13] NOTICE: Finishing ...
[08-Jan-2021 13:46:13] NOTICE: exiting, bye-bye!
[08-Jan-2021 14:00:33] NOTICE: configuration file /usr/local/etc/php-fpm.conf test is successful
[08-Jan-2021 14:00:33] NOTICE: fpm is running, pid 23207
[08-Jan-2021 14:00:33] NOTICE: ready to handle connections
Checking file permissions:
Code: [Select]
root@OPNsense:~ # ls -la /tmp/php-fastcgi.socket-*
srwxr-xr-x 1 root wheel 0 Jan 8 14:19 /tmp/php-fastcgi.socket-0
srwxr-xr-x 1 root wheel 0 Jan 8 14:19 /tmp/php-fastcgi.socket-1Any idea?
edit: this is the firewall log obtained from the shell (while accessing to the web gui from a client). It does not seems that there is any rule blocking it:
Code: [Select]
00:00:00.282300 rule 72/0(match): pass in on igb0: (tos 0x0, ttl 128, id 25963, offset 0, flags [DF], proto TCP (6), length 52)
192.168.91.130.10041 > 192.168.91.1.443: Flags [S], cksum 0x536c (correct), seq 2836207325, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
00:00:00.000071 rule 72/0(match): pass in on igb0: (tos 0x0, ttl 128, id 25964, offset 0, flags [DF], proto TCP (6), length 52)
192.168.91.130.10042 > 192.168.91.1.443: Flags [S], cksum 0x70be (correct), seq 2228559298, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
00:00:00.404254 rule 72/0(match): pass in on igb0: (tos 0x0, ttl 128, id 25974, offset 0, flags [DF], proto TCP (6), length 52)
192.168.91.130.10043 > 192.168.91.1.443: Flags [S], cksum 0xd4c3 (correct), seq 614537712, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
00:00:00.005782 rule 72/0(match): pass in on igb0: (tos 0x0, ttl 128, id 25980, offset 0, flags [DF], proto TCP (6), length 52)
192.168.91.130.10044 > 192.168.91.1.443: Flags [S], cksum 0x67d1 (correct), seq 2702838376, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
00:00:00.585299 rule 73/0(match): pass out on igb2: (tos 0x0, ttl 127, id 16841, offset 0, flags [DF], proto TCP (6), length 52)Log while accessing to the web-gui from the router itself:
Code: [Select]
192.168.91.1.51915 > 192.168.91.1.443: Flags [S], cksum 0x3782 (incorrect -> 0xcef2), seq 1690452735, win 65228, options [mss 16344,nop,wscale 7,sackOK,TS val 2548563096 ecr 0], length 0
00:00:00.000141 rule 68/0(match): pass in on lo0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60, bad cksum ff28 (->292)!)EDIT 2:
I have changed the port assigned to the web-gui under /conf/config.xml , thinking that perhaps a firewall rule could block it, but that din't helped in any way.
Code: [Select]
<webgui>
<protocol>https</protocol>
<ssl-certref>5cf0d67021325</ssl-certref>
<port>4433</port>
<ssl-ciphers/>
<interfaces>lan,opt3,opt4,opt5,opt6,opt1</interfaces>
<compression/>
<nodnsrebindcheck>1</nodnsrebindcheck>
</webgui>But after this change, accessing from the shell of the firewall the output changed from "connection timeout" to
Code: [Select]
root@OPNsense:~ # wget https://192.168.91.1:4433
--2021-01-08 15:48:26-- https://192.168.91.1:4433/
Connecting to 192.168.91.1:4433... connected.
OpenSSL: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
Unable to establish SSL connection.So, I tried to disable https and the output changed again:
Code: [Select]
root@OPNsense:~ # wget http://192.168.91.1:4433
--2021-01-08 15:52:27-- http://192.168.91.1:4433/
Connecting to 192.168.91.1:4433... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2952 (2.9K) [text/html]
Saving to: 'index.html'
index.html 100%[====================================================================================================================================================================================================>] 2.88K --.-KB/s in 0s
2021-01-08 15:52:27 (125 MB/s) - 'index.html' saved [2952/2952]The web-gui is still not accessible from clients, but seems anyway an improvement on fixing this issue.
EDIT 3:
I tried unplugging the two WAN cables, and in this way the web-interface was accessible again. So it seems like some fw rules that were not applied. Applying the update of the firewall also reloaded the rules, and so I got cut-off from the web-gui.
I still need to better investigate on it but at least now I can access the web-gui and better investigate on the issue.
5
18.7 Legacy Series / Re: Problem with NAT configuration on virtual OPNsense
« on: December 01, 2018, 05:31:21 pm »
So many troubles, but at the end I got the hint by alone.
The problem here was not with the NAT, but with the default gateway of the HTTPS server.
As I was moving from a network configuration (internet - draytek router - lan) to a new one, I had still the old router connected while I was configuring the new OPNsense.
This to reduce the troubles and giving me the time to configure all without too many troubles.
The HTTPS request was correctly forwarded, but then the HTTPS server was trying to reply using another gateway.
Updating the gateway of the web-server has fixed the issue
The problem here was not with the NAT, but with the default gateway of the HTTPS server.
As I was moving from a network configuration (internet - draytek router - lan) to a new one, I had still the old router connected while I was configuring the new OPNsense.
This to reduce the troubles and giving me the time to configure all without too many troubles.
The HTTPS request was correctly forwarded, but then the HTTPS server was trying to reply using another gateway.
Updating the gateway of the web-server has fixed the issue
6
18.7 Legacy Series / Re: Problem with NAT configuration on virtual OPNsense
« on: December 01, 2018, 03:06:26 pm »
I add a little info that I have found, but could help.
If, from a computer on the LAN behind OPNsense, I go to https://192.168.178.3/ (that is the WAN ip of OPNsense), then it works.
EDIT:
from a phone connected to the Wifi of the router (192.168.178.1) I cannot access https://192.168.178.3/.
So seems that the NAT rule works only if the connection comes from the LAN interface of OPNsense, but does not work if it comes from the WAN interface.
From the LOG I see an effor for 192.168.178.2, that is the IP of the real nic that is bridged with the OPNsense WAN. So I think that this "red" messages are the problem, but I'm not sure how to fix them.
If, from a computer on the LAN behind OPNsense, I go to https://192.168.178.3/ (that is the WAN ip of OPNsense), then it works.
EDIT:
from a phone connected to the Wifi of the router (192.168.178.1) I cannot access https://192.168.178.3/.
So seems that the NAT rule works only if the connection comes from the LAN interface of OPNsense, but does not work if it comes from the WAN interface.
From the LOG I see an effor for 192.168.178.2, that is the IP of the real nic that is bridged with the OPNsense WAN. So I think that this "red" messages are the problem, but I'm not sure how to fix them.
7
18.7 Legacy Series / (SOLVED) Problem with NAT configuration on virtual OPNsense
« on: December 01, 2018, 02:47:59 pm »
Hi all!
I'm new to OPNsense, and I am trying to make a network change to use it. Hope that somebody can give me a good hint to fix this issue, so that I can start using OPNsense...!
I have this network structure:
INTERNET - ROUTER (192.168.178.1, a Fritz!Box) - OPNsense (192.168.178.3) (virtual Host inside a FreeNAS server, binded to a NIC with ip 192.168.178.2) - LAN (192.168.91.0/24).
I am trying to configure some NAT rules, for example a NAT from wan port 443 to 192.168.91.216 port 443.
On the router I add the rules needed NAT rule, WAN port 443 to 192.168.178.3 (that is the WAN of the OPNsense virtual host).
Then, on OPNsense I add another new NAT from WAN of OPNsense to the final host 192.168.91.216
and this creates automatically a new firewall rule (in Firewall: Rules: WAN):
.
Looking at the live-view of the log, I get
.
So, seems all OK but the page is not loading.
If I change the rule on the router to point another bare-metal firewall box (a Draytek router, with the NAT configured in the same way) then it works. So this means that the problem is not on the first router. The final host has it's firewall disabled, to avoid troubles on the end point.
So I think that the problems could be:
- something is configured wrong on the FreeNAS server and this does not make OPNsense work properly. Seems strange to me becouse there aren't many things to configure there.
- there is something configured wrong on OPNsense that does not make it working, perhaps an option that I didn't cared but is needed. Perhaps the problem is that the WAN interface of OPNsense is a private ip?
Any hint?
I'm new to OPNsense, and I am trying to make a network change to use it. Hope that somebody can give me a good hint to fix this issue, so that I can start using OPNsense...!
I have this network structure:
INTERNET - ROUTER (192.168.178.1, a Fritz!Box) - OPNsense (192.168.178.3) (virtual Host inside a FreeNAS server, binded to a NIC with ip 192.168.178.2) - LAN (192.168.91.0/24).
I am trying to configure some NAT rules, for example a NAT from wan port 443 to 192.168.91.216 port 443.
On the router I add the rules needed NAT rule, WAN port 443 to 192.168.178.3 (that is the WAN of the OPNsense virtual host).
Then, on OPNsense I add another new NAT from WAN of OPNsense to the final host 192.168.91.216
and this creates automatically a new firewall rule (in Firewall: Rules: WAN):
.Looking at the live-view of the log, I get
.So, seems all OK but the page is not loading.
If I change the rule on the router to point another bare-metal firewall box (a Draytek router, with the NAT configured in the same way) then it works. So this means that the problem is not on the first router. The final host has it's firewall disabled, to avoid troubles on the end point.
So I think that the problems could be:
- something is configured wrong on the FreeNAS server and this does not make OPNsense work properly. Seems strange to me becouse there aren't many things to configure there.
- there is something configured wrong on OPNsense that does not make it working, perhaps an option that I didn't cared but is needed. Perhaps the problem is that the WAN interface of OPNsense is a private ip?
Any hint?
Pages: [1]