Menu

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.

Show posts Menu

Messages - felippe

#1
I've fixed this issue, and there is no wonder why my post didn't get any replies - the problem I described, well, let's say it was misleading.

There is nothing to do with the security certificate - Firefox was returning the error because the security certificate was for the OPNsense web UI, and not for Nextcloud. As soon as I chose a different port for the OPNsense web UI (I changed from 443 to 8443), the error changed to "The page cannot be displayed" (404). This error actually triggered the solution - all I had to do was to enable "Reflection port forwards" in Firewall: Settings: Advanced.

I hope this may help another newbie like me...
#2
Hello all,

I have just migrated from a Meraki MX64 security appliance to OPNsense and I am experiencing an issue I didn't have before this change.

There is a self-hosted Nextcloud server (Ubuntu 20.04 Server on which only Nextcloud (Snap) is installed. OPNsense is running on a SuperMicro Atom server with two physical interfaces. A managed switch connects everything together. Apart from the firewall, nothing else has changed.

The Nextcloud server sits in the DMZ VLAN. The TLS encryption is provided by a Let's Encrypt certificate.

I have no issues accessing the server from the internet using the "https://nextcloud.mydomain.com" URL. From inside the LAN, I can access the server using the IP address ("172.16.0.20"), but when accessing it using the FQDN I get the error below. If using a VPN, there is NO error.


Warning: Potential Security Risk Ahead
[...]
nextcloud.mydomain.com uses an invalid security certificate.
The certificate is not trusted because it is self-signed.
Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT
View Certificate


I tried to delete all the related cookies, emptied the cache, delete the certificate error exceptions. Dry-running the certificate renewal shows no issues, and I have even successfully renewed the certificate. I have also followed the documentation related to intermediary certificates, but this didn't fix my issue either.

Screen captures with the firewall rules for the DMZ VLAN and the NAT port forwarding are attached.

I will be grateful for any feedback.

Regards,

Valentin
#4
I have a Supermicro SC502L-200B 1U chassis, optimized for Intel Atom series platform. This is a half depth chassis, 9.8" (249 mm) into which I installed a Flex-ATX Supermicro motherboard: X7SPE-HF-D525.

There are no fans involved in cooling the Atom CPU on the motherboard, and no chassis fans. The only fan is inside the PSU (PWS-202-1H).

I measured the noise level, using a free iPhone app (DecibelX), for 30 seconds; the average was 50.5 dB, min: 49.5 dB, max: 52.2 dB, peak: 56.8 dB. The iPhone's microphone was in the immediate proximity of the rear of the server.

I did test a fan-less PSU - obviously, all went 100% quiet, but some issues with powering off and on the server, made me to stick with the original PSU. Also fitting the PSU inside the chassis wasn't as straight forward as I thought.

The system is racked inside a small, wooden 6U cabinet, in the front room. The front door is always shut, the rear is open, facing a wall (the distance from the rear of the cabinet to the wall is about 10 cm / 4").

For me and my wife, the noise is not disturbing - we watch the TV, hardly noticing it, but when there is no other noise source, the noise coming from the fan is quite noticeable (luckily, apart from the cat, no one sleeps in this room).

The conclusion is that I am very happy with my OPNsense setup, and I would recommend the Supermicro chassis to anyone who wants a neat cabinet. I could take some pictures if anyone is interested.
#5
Hello all,

In the attached file is the network diagram of my home network. Some details which may help in identifying a solution to the problem I am experiencing:

- the focus is on "opnsense" - "switch" - "truenas"
- the VLANs and interfaces of interest are:
VLAN 1 (MGMT) tagged on em0 (opnsense), port 10 (switch), lagg0 (truenas), BMC (truenas)
VLAN 2 (USERS) tagged on same ports as VLAN 1 less BMC, and untagged on port 6 (switch)
- truenas: VLAN 1 (MGMT) IP address:
192.168.1.2 tagged on BMC (IPMI interface)
192.168.1.3 tagged on lagg0 (igb0 and igb1 LACP link aggregation)
- truenas: VLAN 2 (USERS) IP address:
192.168.2.3 tagged on lagg0 (igb0 and igb1 link aggregation)
- opnsense: VLAN 1 (MGMT) IP address: 192.168.1.1 tagged on em0
- opnsense: VLAN 2 (USERS) IP address: 192.168.2.1 tagged on em0
- rpi4: IP address: 192.168.2.21
- switch: VLAN 1 (MGMT) IP address: 192.168.1.4 tagged on ports 10, Link Aggregation 1 (ports 3 and 4, LACP), and 5
- switch: VLAN 2 (USERS) tagged on ports 10 and Link Aggregation 1, and untagged on port 6

The only firewall rules configured on opnsense are:
[MGMT] Pass | Protocol IPV4 * | Source: MGMT Net | Source Port * | Destination: * | Dest. Port * | Gateway * | Description: Allow all
[USERS] Pass | Protocol IPV4 * | Source: USERS Net | Source Port * | Destination: * | Dest. Port * | Gateway * | Description: Allow all

The problem:

- access the web UI of truenas from rpi4 web browser on 192.168.1.3 and
- truenas SSH access from rpi4: $ ssh root@192.168.1.3
HTTP / HTTPS connection drops after less then a minute, then restore, drops again and so on; SSH connection drops and, obviously, doesn't restore without me entering the command again.

I do not experience this issues when using the 192.168.2.3 IP address. Even more: no lost connectivity when assigning a static IP to rpi4 in VLAN 1 [MGMT] (ex. 192.168.1.10). So everything works fine when both truenas and rpi4 are in the same network.

And, no issues when accessing the web UI for the IPMI interface on 192.168.1.2 (VLAN 1) from rpi4 with an IP address on VLAN 2 - so this time, no inter-VLAN routing issues.

Would this be an opnsense routing issue or truenas link aggregation one? The next step in troubleshooting will be to "break" the link aggregation and see if the problem persists when using a standard link, but I would like to have the community's feedback first. Just to add that everything was working fine when I had another VLAN configured on all devices (VLAN 3), but then I decided to get rid of it and simplify the design by bringing those devices in VLAN 2.

Your input will be appreciated.