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

Topics - tonys

#1
Hi all,

I have an OpenVPN Access server running on a dedicated LAN interface which is DMZ'd with the three ports used by Access Server forwarded to its LAN address. I previously set up bogon alias filters in a (futile) attempt to filter out the worst attackers detected by Access Server and fail2ban. I *thought* the filter alias was working but realized that the offending IP's are still being forwarded to the dedicated LAN despite putting in a blocking rule in both the WAN and DMZ interfaces. It turns out that the automated "let out anything from firewall host itself" rules (uneditable) are passing the packets before my filters rules are hit and bypassing my rules. The documentation indicates that port forwarding can indeed bypass filter rules and that's what appears to be happening.

Is there any practical way to insert filter alias rules to block the offending IP addresses when port forwarding is being used? There's some vague reference to adding some filter process in this scenario but I can't figure out how to do it. If these forwarded DMZ'd ports can't be filtered at all, then I suppose I need to route them in a different way?

Thanks.
#2
Hi all,

I'm running OPNsense 25.1.3-amd64 FreeBSD 14.2-RELEASE-p2 OpenSSL 3.0.16.

Over the past two days, my firewall alias tables are no longer refreshing or updating on a daily basis. Things were running fine prior to 3/19/25 and as I added new URL Table IP's, they got pulled in and blocked. The latest IP's are no longer being blocked. I read through many posts here as well as the OPNSense docs but none of the suggestions here are working.

I added a cron job to refresh/reload the aliases (see the Cron attachment) every 30 minutes but no change. I checked the alias updates and it's indeed set to Daily, still no luck. I'm out of ideas short of manually hacking the XML file to add new IP's but that probably wouldn't force a reload either.

Is there any way to force a refresh/reload? I can't find this in the docs anywhere. It's clear from the Last Update attachment that only 33 IPs are loaded in the alias table and the two most recent additions (see Alias Table attachment) are not loaded since last update was two days ago prior to me adding these additional IPs. The first 33 IP's are being blocked properly but unfortunately (for me), the last two entries are hitting my DMZ server hard with over 60,000 attempts in the past two days. I really need to get these loaded into the tony_bogons table ASAP.

Ideas? Thanks...
#3
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.




#4
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
#5
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...
#6
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.