Messages

1

24.1 Legacy Series / Re: Trouble accessing HTTP-only web sites via port 80

« on: June 04, 2024, 09:26:27 pm »

"Well it does no impact openvpn cause the webgui uses tcp port 443 and openvpn uses udp port 443. So thats okay."

Clarification of OpenVPN ports:

TCP 443: used only for client web access from external IP addresses. Never used unless the OpenVPN client fails.
TCP 943: used for admin web access from external IP addresses. This is used to maintain OpenVPN.
UDP 1194: used for all traffic to/from the OpenVPN server with external clients. UDP 1194 is the normal operating mode for OpenVPN clients. TCP port 443 can be used for better reliability but slower traffic processing. There is no UDP 443 that I've found in the OpenVPN documentation.

What confuses me is that there are identical port forwards and firewall rules for ports 80, 443, 943, and 1194 but only port 80 fails. I don't understand why port 80 is so "special" to OPNsense that it doesn't follow the same rules as 443, 943, and 1194.

Also confusing is that I can access HTTP ports on port 80 from any device's web browser and replies come back to the correct device as expected. The only failing reply is LetsEncrypt which starts a web server on port 80 of the OpenVPN server during certbot renewal. I assume LetsEncrypt sends a request over port 80 but I'm unable to see this traffic moving through the firewall in either direction. There's no documentation of how the web server LetsEncrypt running on port 80 communicates to the outside world and I have yet to be able to see this traffic.

As an aside, I tried using lego to generate certificates via port 443 on the OpenVPN server and this almost works. By almost, I mean the communication process with the outside world via port 443 is successful but the certs I get back don't work with OpenVPN for some reason.

I'll investigate your suggestion regarding SLACC on the acme client but I don't understand anything about this process. I'll also investigate the reverse proxy but again, I have no understanding of this process either.
 

2

24.1 Legacy Series / Re: Trouble accessing HTTP-only web sites via port 80

« on: June 03, 2024, 11:16:12 pm »

Attached are my current System settings. The web GUI redirect is indeed disabled. However, I'm using 443 for OPNsense which does NOT impact OpenVPN access from an external IP address. Users outside my home network can find and log into OpenVPN.

The port 80 replies from LetsEncrypt are MIA. Can you please explain why I would need to change the OPNsense GUI to a different port (e.g. 1443?) to fix port 80 replies? I find this very confusing.

UPDATE: I changed the port to 1443 but this did NOT fix the LetsEcrypt renewal. I get the same error so I'm setting the HTTPS port back to 443 for the time being.

Thanks,
Tony

3

24.1 Legacy Series / Re: Trouble accessing HTTP-only web sites via port 80

« on: June 03, 2024, 03:29:42 am »

@Monviech,

The attached screen shots show the following:

1. OPnsense port forwards to my DMZ server on 192.168.30.3 (80, 443, 943, 1194)
2. OPNsense firewall rules to the the DMZ server
3. UFW firewall rules on the DMZ server itself
4. LetsEncrypt failure when updating over port 80

I have an OpenVPN webserver behind OPNsense which works fine on ports 443, 943, and 1194. LetsEncrypt requires port 80 to be open during cert updates which is also forwarded, firewall-ruled and open on the OpenVPN server. OpenVPN itself works fine in this configuration and all incoming requests on ports 443, 943, and 1194 work fine. However, LetsEncrypt over port 80 doesn't work. I'm baffled by this as I have the same settings for port 80 as for the other ports.

4

24.1 Legacy Series / Trouble accessing HTTP-only web sites via port 80

« on: June 02, 2024, 12:06:11 am »

OPNsense 24.1.8-amd64
FreeBSD 13.2-RELEASE-p11
OpenSSL 3.0.13
Suricata 7.0.5_1

I have an ongoing problem wherein LAN access to certain HTTP web sites are being blocked. Here are a few sites I'm unable to access:

1. http://repo.feed.flightradar24.com (using "sudo apt update" under RaspberryPi OS)
    Err:7 http://repo.feed.flightradar24.com flightradar24 InRelease Connection failed [IP: 52.217.205.24 80] 

2. Renewing LetsEncyrpt SSL certificate: (using "sudo certbot renew" under Ubuntu Linux 22.04)
   The Certificate Authority failed to download the challenge files from the temporary standalone webserver started    by Certbot on port 80     

3. Also, a few Facebook pages that don't use HTTPS are being blocked (e.g. via iOS access on iPhones)

Considering these are outbound port 80 requests to external sites, I assume some firewall rule must be blocking them on the way in from the various LAN servers. I can't be sure though because it's really not clear where the blockages are occurring. Digging through the log and json files in /var/log/filter and /var/log/suricata, I found references to the IP address in issue 1 above but don't understand what they're telling me:

/var/log/filter/latest.log:

<134>1 2024-06-01T15:40:47-05:00 OPNsense.home.lan filterlog 4446 - [meta sequenceId="114698"] 10,,,0,igc1,match,nat,out,4,0x10,,64,0,0,DF,6,tcp,40,192.168.1.10,52.217.205.24,43298,80,0,S,64240,,0,,
filter_20240601.log:<134>1 2024-06-01T15:40:47-05:00 OPNsense.home.lan filterlog 4446 - [meta sequenceId="114699"] 101,,,e3758d9e17f4ad487875821fc183e910,igc1,match,pass,out,4,0x10,,64,0,0,DF,6,tcp,40,67.163.46.185,52.217.205.24,64548,80,0,S,64240,,0,,     

/var/log/suricata/eve.json:

{"timestamp":"2024-06-01T15:41:10.070699-0500","flow_id":1725326563306316,"in_iface":"igc0","event_type":"alert","src_ip":"192.168.1.10","src_port":43298,"dest_ip":"52.217.205.24","dest_port":80,"proto":"TCP","pkt_src":"wire/pcap","tx_id":0,"alert":{"action":"allowed","gid":1,"signature_id":2013504,"rev":6,"signature":"ET POLICY GNU/Linux APT User-Agent Outbound likely related to package management","category":"Not Suspicious Traffic","severity":3,"metadata":{"created_at":["2011_08_31"],"updated_at":["2020_04_22"]}},"http":{"hostname":"repo.feed.flightradar24.com","url":"/dists/flightradar24/InRelease","http_user_agent":"Debian APT-HTTP/1.3 (2.2.4)","http_method":"GET","protocol":"HTTP/1.1","length":0},"app_proto":"http","direction":"to_server","flow":{"pkts_toserver":10,"pkts_toclient":3,"bytes_toserver":822,"bytes_toclient":166,"start":"2024-06-01T15:40:46.991532-0500","src_ip":"192.168.1.10","dest_ip":"52.217.205.24","src_port":43298,"dest_port":80}}
                   
How do I track these down? I've been all over the OPNSense pages for weeks but I'm not making any progress. Any help would be greatly appreciated.

5

24.1 Legacy Series / Re: How can I change the Aliases setting at the command line?

« on: May 23, 2024, 07:05:22 pm »

Yes, this worked! Thank you!

6

24.1 Legacy Series / How can I change the Aliases setting at the command line?

« on: May 23, 2024, 06:47:28 pm »

I accidentally turned on "All" in the aliases setting under Firewall->Diagnostics->Aliases. I had no idea the alias list was over 42,000 items and every time I go to this page (see attached screenshot), the page immediately freezes before I can change the setting back to the default of 20.

Alternatively, I've been searching through config.xml looking for that setting but can't find it. Where is this setting located?

Thanks...

OPNsense 24.1.7_4-amd64
FreeBSD 13.2-RELEASE-p11
OpenSSL 3.0.13

7

24.1 Legacy Series / LAN routing conflict between OPNsense and OpenVPN web servers

« on: May 09, 2024, 10:36:12 pm »

I'm running an OpenVPN server on a Raspberry Pi behind the OPNsense firewall in order to filter out the vast majority of bot attacks before they reach OpenVPN/Fail2ban. (I originally tried placing the Pi before the firewall but the outrageous number of bot attacks overwhelmed the OpenVPN server, making it totally unresponsive, not to mention the conflicts between the OPNSense and OpenVPN servers, both running on port 443.) Everything works correctly from the internet (outside my LAN) but connection requests originating from inside my LAN (i.e., LetsEncrypt cert updates) and referencing the external Dynu DNS server are not getting to the Raspberry Pi host. Instead, they're going to the OPNSense firewall and getting blocked because port 80 is not open there. (Even if OPNsense port 80 was open, this is the wrong place for LetsEncrypt replies as they must route to the requesting server.) Port 80 is open on the Raspberry Pi for LetsEncrypt replies but OPNSense isn't routing them to the Raspberry Pi. How do I know this? If I open a web browser to my Dynu domain "tshome.mywire.org" from inside my LAN, I get the OPNSense login page instead of the OpenVPN page. My Dynu domain "tshome.mywire.org" should always route to the Rapsberry Pi/OpenVPN, regardless of whether I'm inside or outside my LAN. Again, outside my network, this works fine and my collaborators do see the OpenVPN login page and can login there. Therefore, this issue is isolated only to the LetsEncrypt update process when inside the LAN.

Unfortunately, the LetsEncrypt cert updates are intimately tied to the "tshome.mywire.org" domain and LetsEncrypt expects to see its requests come back on the Raspberry Pi's port 80 as shown below:

****************************************************************************
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/tshome.mywire.org.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Renewing an existing certificate for tshome.mywire.org

Failed to renew certificate tshome.mywire.org with error: Some challenges have failed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/tshome.mywire.org/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
****************************************************************************

Because those port 80 replies are going to the OPNSense web server page and getting rejected, I can't renew my certs and I'm running out of time.

Further info: Yes, I have ports 80 and 443 NAT translated to the Raspberry Pi so I expected all incoming traffic to go there. This works correctly from the outside world but not within my network where LetsEncrypt expects to receive replies. See the attached screenshot.

How do I set a rule for OPNsense to understand that outgoing requests from my LAN to "tshome.mywire.org" must return replies on port 80 to the Raspberry PI behind the OPNsense firewall?

Thank you...

8

24.1 Legacy Series / Re: flowd_aggregate process burning high CPU in OPNsense 24.1.6-amd64

« on: May 09, 2024, 01:01:06 am »

Resetting the flowd database has indeed helped. Later today though, I noticed 238% CPU usage by the suricata process which I ended up killing manually in the console because the GUI again became unresponsive. Following this, I rebooted the router and it’s back to normal for now.

Thanks for pointing out the flowd reset/repair procedure - I hadn’t even looked at that page before.

9

24.1 Legacy Series / flowd_aggregate process burning high CPU in OPNsense 24.1.6-amd64

« on: May 08, 2024, 02:27:11 am »

Ive been running OPNsense 24.1.6-amd64 since it's release. Last night, I started having loss of all networks after noticing that the CPU load was running near 100% and the Protectli VP 2420 was very hot. I couldn't access the router from any interface and ended up forcing the VP2420 to shutdown manually. After a few hours of cooling off, the system came up fine today but then I noticed high CPU usage being caused by the flowd_aggregate process. The box started heating up again and network access was very slow. Top showed a python process running at nearly 100% and I was able to isolate it to the flowd_aggregate process. I've now turned off Insight Aggregator in the GUI and will leave it off for a day or two to determine if it's the only culprit. I've seen numerous posts with similar complaints on older releases of OPNSense.

Is anyone familiar with this issue? All networks stall out completely on all interfaces and the entire VP2420 becomes inaccessible. In day to day use, I rarely see CPU usage exceed 20% and most of the time all 4 cores are essentially idle. See the attached Monitor log screenshot.