"Recent posts
#1
General Discussion / Re: os-OPNWAF - Request Header...
Last post by aaron_willowbrooke - May 09, 2026, 11:48:33 PMGood catch, I'll sanity check what already exists (figured this was a typical override with incrementing 0->9 priority separate from baseline) but will review and spruce this up. Thanks a ton again, things are spinning beautifully here!
#2
General Discussion / Re: os-OPNWAF - Request Header...
Last post by Monviech (Cedrik) - May 09, 2026, 11:19:47 PMCool thank for sharing :)
Just keep in mind that your rule ID might overlap with IDs that the templating engine generates for crs-exclusions.conf. (If you exclude rules in the GUI it generates custom modsecurity rules as well)
It also starts at 100001.
Just keep in mind that your rule ID might overlap with IDs that the templating engine generates for crs-exclusions.conf. (If you exclude rules in the GUI it generates custom modsecurity rules as well)
It also starts at 100001.
#3
General Discussion / Re: os-OPNWAF - Request Header...
Last post by aaron_willowbrooke - May 09, 2026, 10:58:35 PMThanks a ton! This is working as expected, outlining steps for others on the internet:
1.) SSH into the OPNsense
2.) Gather the upcoming $OriginHeaderValue value with the header secret from CloudFront -> Distribution -> Origins -> OPNsense Origin -> Edit -> "Add custom header"
3.) vi /usr/local/etc/apache24/modsecurity-user/001-x-originated-from-cloudfront.conf
SecRule REQUEST_HEADERS:X-Originated-From-CloudFront "!@streq $OriginHeaderValue" "id:100001,phase:1,deny,status:403,log,msg:'Denied - Request Bypassed the CDN'"
4.) service apache24 reload
Works for me right away, a lack of this header or an invalid value thereof 403 as desired. Note that my rule as-written applies for ALL Virtual Hosts in os-OPNWAF, you may need to refactor if you split some public stuff across CloudFront-sourced and direct-to-OPNsense concurrently.
Type opnsense-business
Version 26.4_6
os-OPNWAF (installed) 2.2_1 4.75MiB 1 OPNsense Web Application Firewall using the well-known Apache webserver
1.) SSH into the OPNsense
2.) Gather the upcoming $OriginHeaderValue value with the header secret from CloudFront -> Distribution -> Origins -> OPNsense Origin -> Edit -> "Add custom header"
3.) vi /usr/local/etc/apache24/modsecurity-user/001-x-originated-from-cloudfront.conf
SecRule REQUEST_HEADERS:X-Originated-From-CloudFront "!@streq $OriginHeaderValue" "id:100001,phase:1,deny,status:403,log,msg:'Denied - Request Bypassed the CDN'"
4.) service apache24 reload
Works for me right away, a lack of this header or an invalid value thereof 403 as desired. Note that my rule as-written applies for ALL Virtual Hosts in os-OPNWAF, you may need to refactor if you split some public stuff across CloudFront-sourced and direct-to-OPNsense concurrently.
Type opnsense-business
Version 26.4_6
os-OPNWAF (installed) 2.2_1 4.75MiB 1 OPNsense Web Application Firewall using the well-known Apache webserver
#4
Intrusion Detection and Prevention / Re: Default deny rule not work...
Last post by cookiemonster - May 09, 2026, 10:38:55 PMYour WAN is a private range so the rest of the setup might be at play.
That said, on a default OPN installation, the LAN has a default allow all out rule so all clients on lan will be allowed out via WAN. The purpose is to default to new users as a consumer-type of device. Any new interfaces don't have it.
In light of this, the NAT rule is unnecessary on a default LAN.
That said, on a default OPN installation, the LAN has a default allow all out rule so all clients on lan will be allowed out via WAN. The purpose is to default to new users as a consumer-type of device. Any new interfaces don't have it.
In light of this, the NAT rule is unnecessary on a default LAN.
#5
General Discussion / Re: os-OPNWAF - Request Header...
Last post by Monviech (Cedrik) - May 09, 2026, 10:18:39 PMRight now I don't know of a way how this would be possible in the current GUI.
Though in the latest OPNWAF version we added new modsecurity and apache import folders in which you can drop custom configs.
You can probably create a custom modsecurity rule that can drop all traffic that does not match a certain header and add that to the modsecurity import folder.
/usr/local/etc/apache24/modsecurity-user/
Though in the latest OPNWAF version we added new modsecurity and apache import folders in which you can drop custom configs.
You can probably create a custom modsecurity rule that can drop all traffic that does not match a certain header and add that to the modsecurity import folder.
/usr/local/etc/apache24/modsecurity-user/
#6
General Discussion / Re: Help with GeoIP and csv fo...
Last post by ChrisC - May 09, 2026, 10:09:33 PMQuote from: meyergru on May 09, 2026, 09:45:12 AMInteresting. Their database seems to be bigger at 17 MByte than Maxmind's GeoIP Lite at 11 MByte.
I just emailed them if they could provide a compressed CSV version like Maxmind.
That being said, if you need more accurate data than Maxmind's, which is also free, you can use ipinfo.io, like explained here.
I did think about mailing them, but I thought I should at least try and figure out some of it myself!
Thanks, I'll check it out!
#7
Q-Feeds (Threat intelligence) / Re: Q-Feeds and Adguard Home
Last post by Patrick M. Hausen - May 09, 2026, 10:07:59 PMPerfectly possible, I run that at home. Open a ticket with Q-Feeds support to get a second API key for use in AGH.
AGH does need an upstream server, though. So if you don't want to run Unbound as a recursive server, you need to cofigure your ISP, 1.1.1.1, or whatever you prefer. I use Unbound.
AGH does need an upstream server, though. So if you don't want to run Unbound as a recursive server, you need to cofigure your ISP, 1.1.1.1, or whatever you prefer. I use Unbound.
#8
Hardware and Performance / Re: 10GBASE-T RJ45 SFP+ Copper...
Last post by alhaddar - May 09, 2026, 09:54:06 PMHi ,
I recently made a post about my Firewall Mini PC specs. I mistakenly wrote that the CPU is an Intel N150, but the correct CPU is actually an Intel i3‑N300.
Here are the correct specifications:
CPU: Intel i3‑N300
Ports: 2x 10G SFP+ and 3x 2.5G (i226‑V)
RAM: DDR5
Storage: NVMe
OS: OPNsense (latest)
My apologies for the confusion. The rest of the details about the 10GBASE‑T SFP+ modules and compatibility remain the same.
Thank you to everyone who responded, and I appreciate your understanding.
I recently made a post about my Firewall Mini PC specs. I mistakenly wrote that the CPU is an Intel N150, but the correct CPU is actually an Intel i3‑N300.
Here are the correct specifications:
CPU: Intel i3‑N300
Ports: 2x 10G SFP+ and 3x 2.5G (i226‑V)
RAM: DDR5
Storage: NVMe
OS: OPNsense (latest)
My apologies for the confusion. The rest of the details about the 10GBASE‑T SFP+ modules and compatibility remain the same.
Thank you to everyone who responded, and I appreciate your understanding.
#9
German - Deutsch / Empfehlungen für den Umstieg v...
Last post by Jayfrog - May 09, 2026, 09:51:41 PMHallo werte Gemeinde!
Kurz zu Erlärung wie mein altes Setup mit IPv6 lief, welches ich ebenfalls nach Anleitung von euch
nachempfunden habe.
WAN - 56 Präfix anfordern, zu letzt war, Send Präfix hint, aus
LAN/OPT1 - Track Interface, LAN Präfix standart 0, OPT1 = 1. Allow manual adjustment of DHCPv6 and Router Advertisements, war auch aktiv.
DHCPv6 war aus, Router Advertiser stand auf Assisted.
Das lief soweit bisher problemlos, doch mit dem Umstieg habe ich so meine Schwierigkeiten.
Die KI war zwar wirklich hilfreich, aber ich hätte hier so oder so noch mal um Korrektur dazu gebeten.
Habt ihr vielleicht ein paar Ratschläge, wie man es ähnlich simple einrichtet wie zuvor, ohne aktives DHCPv6?
Lg!
#10
General Discussion / os-OPNWAF - Request Header Ins...
Last post by aaron_willowbrooke - May 09, 2026, 09:26:27 PMHey all, was wondering if there's built-in functionality within os-OPNWAF to perform request header inspection.
I have an on-prem hypervisor and use CloudFront as a cache-less reverse proxy on a flat rate plan as such:
1.) Client queries public DNS A/AAAA for host.domain.tld
2.) Route 53 responds with an Alias A/AAAA to d123example.cloudfront.net
3.) Client connects to CloudFront, initial HTTPS cert/host/WAF check
4.) Because CloudFront is cache-less, if the WAF inspection passes, begins an origin request to DNS A for onprem.domain.tld which is updated over time with os-ddclient
5.) CloudFront connects to my edge OPNsense (hardware Deciso 697 appliance) via PubIp:443 per the onprem.domain.tld record's IPv4 value
6.) Edge OPNsense uses its Destination NAT scoping CloudFront IPs as the allowed source (CLOUDFRONT_ORIGIN_FACING from AWS' ip_ranges.json) towards This Firewall:443 with a corresponding firewall rule on the WAN interface
7.) os-OPNWAF receives the request and forwards onto the corresponding vhost/location pairs based on Host header
This is working completely fine right now from a usability perspective, but in addition to source IP restrictions I'd also like to perform requester header inspection and drop if not matching. In CloudFront I use a X-Originated-From-CloudFront custom origin request header for all my workflows, for cloud/hybrid/on-prem destinations alike, because ideally you can then inspect the value origin-side and drop if not matching. This is outlined by AWS as a design pattern here:
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html#restrict-alb-add-custom-header
However, when reviewing os-OPNWAF's Web GUI settings, I only see options to Add/Merge/Unset/etc. request headers, but no way to inspect them. The main reason I bought an official appliance was for OPNsense Business licensing (plus the niceties of the hardware, this unit is wonderful) which includes os-OPNWAF and was hoping to replace my on-prem NGINX -> Anubis -> Origin flow with it where NGINX was performing request header inspection.
Before I get to modifying the underlying Apache config of os-OPNWAF I was wondering if there's a known implementation pattern of doing:
Check Request Header
If Request Header Value != Desired Value
Drop Request
I'd prefer to not add any other plugins to my OPNsense if possible, i.e. throwing up the NGINX-based plugin and whatnot seems heavy for the firewall, if not currently possible I can accept os-OPNWAF's current features and keep my NGINX for header inspection, but it would be nice if request header inspection was added as a feature.
Thanks in advance for any insights!
I have an on-prem hypervisor and use CloudFront as a cache-less reverse proxy on a flat rate plan as such:
1.) Client queries public DNS A/AAAA for host.domain.tld
2.) Route 53 responds with an Alias A/AAAA to d123example.cloudfront.net
3.) Client connects to CloudFront, initial HTTPS cert/host/WAF check
4.) Because CloudFront is cache-less, if the WAF inspection passes, begins an origin request to DNS A for onprem.domain.tld which is updated over time with os-ddclient
5.) CloudFront connects to my edge OPNsense (hardware Deciso 697 appliance) via PubIp:443 per the onprem.domain.tld record's IPv4 value
6.) Edge OPNsense uses its Destination NAT scoping CloudFront IPs as the allowed source (CLOUDFRONT_ORIGIN_FACING from AWS' ip_ranges.json) towards This Firewall:443 with a corresponding firewall rule on the WAN interface
7.) os-OPNWAF receives the request and forwards onto the corresponding vhost/location pairs based on Host header
This is working completely fine right now from a usability perspective, but in addition to source IP restrictions I'd also like to perform requester header inspection and drop if not matching. In CloudFront I use a X-Originated-From-CloudFront custom origin request header for all my workflows, for cloud/hybrid/on-prem destinations alike, because ideally you can then inspect the value origin-side and drop if not matching. This is outlined by AWS as a design pattern here:
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html#restrict-alb-add-custom-header
However, when reviewing os-OPNWAF's Web GUI settings, I only see options to Add/Merge/Unset/etc. request headers, but no way to inspect them. The main reason I bought an official appliance was for OPNsense Business licensing (plus the niceties of the hardware, this unit is wonderful) which includes os-OPNWAF and was hoping to replace my on-prem NGINX -> Anubis -> Origin flow with it where NGINX was performing request header inspection.
Before I get to modifying the underlying Apache config of os-OPNWAF I was wondering if there's a known implementation pattern of doing:
Check Request Header
If Request Header Value != Desired Value
Drop Request
I'd prefer to not add any other plugins to my OPNsense if possible, i.e. throwing up the NGINX-based plugin and whatnot seems heavy for the firewall, if not currently possible I can accept os-OPNWAF's current features and keep my NGINX for header inspection, but it would be nice if request header inspection was added as a feature.
Thanks in advance for any insights!
