Messages

A) if I pass the data to my backend server unencrypted this allows Surricata running on LAN to scan the actual payload, therefore making it more effective.

Yes, otherwise Suricata won't be able to inspect the encrypted traffic and would minimize the effectiveness of inspection

B) The source of all requests now appears to be the firewall itself, as it's running the reverse proxy. Does this make Surricata less effective? Does this mean it could start blocking my reverse proxy? If yes, is there a way around it? Does it make a difference as listening on LAN is behind NAT anyway?

XFF is how you 'know who requested the traffic', you will need to make sure that the Reverse Proxy you setup in the OPNSense is adding the XFF and that you can inspect/account for that data - that said, make sure you setup Nginx/your-web-host to handle the redirects correctly - I had to learn about extra conf options for Nginx to operate correctly behind Traefik as I'd have really odd port issues otherwise

C) I don't see a way to configure nginx as a transparent proxy using the official plugin. Is this correct? I could use X-Forwarded-For, but this apparently doesn't work with IPS, am I right? Or does it?

It does, but... only if you set it up correctly - you can have the XFF value be replaced in the 'source' via Suricata settings and for you, that sounds like what you will want to do - this "SHOULD" tell the IPS to block the XFF address not itself. For me, I have an external system parsing a specific set of 'xffeve.json' events that does replace the 'source' IP with the 'XFF' IP and so that system (CrowdSec) will add the XFF/source to the Firewall and block it - I do not know if the IPS (using Suricata's built in blocker) will handle this variation correctly - I do not IPS, I just reactive-IDS (add to firewall)

D) In case of a detected intrusion will only the current connection be dropped or everything from that IP (reverse proxy potentially)

Again, using XFF correctly you can mitigate this

E) is there another way I could make WAF + TLS offloading + Surricata IPS work?

IMHO - it is a bit more useful to have Suricata in an IDS mode, customize the 'custom.yaml' for Suricata so it outputs an eve event log with the source IP replaced with the XFF IP, name it something like xffeve.json and have CrowdSec parse that log. CrowdSec will add the IP to your firewall in very short time, and you can setup CrowdSec Multi-Server (one Multi-Server instance is free) and protect quite a group of things so long as you are able to connect all the Agents (Parsers/Blockers/Appsec) back to your LAPI. Yes I am suggesting a whole new Plug-in (a native OPNSense one) to solve the issue - but as far as terminating TLS/SSL you must use an actual Reverse Proxy, and that means XFF is now in the picture, there is no 'transparent reverse proxy' here, that would only happen if you are not terminating TLS/SSL and doing pass-through (which you can do in some reverse proxies... but you have to have a good reason to do this - and that would leave the traffic encrypted, which you do not want...)

Just an update, this Git Repo got a pretty sizable update this week as I changed how the script interacts with BIND.

Instead of doing per item requests it now does an AXFR (Zone Transfer) for the Forward or Reverse Zones and then checks if those items should exist or not. Now it will add missing and remove extra from BIND quite successfully and completely.

If you can "drill/dig -x <ip_address>" (drill or dig, whichever you have installed) or "drill/dig <hostname>.<localdomain>.<tld>" and get expected values back, then yes your hosts are getting DNS set correctly and your OPNSense 'should' be able to resolve these via the Alias system

If that isn't working, you might want to make sure that your OPNSense is using the DNS you are, you can tell the OPNSense not to use its internal DNS system and use whatever you have set in System -> Settings -> General by check marking the "Do not use the local DNS service as a nameserver for this system" option on that page. In short, I'm not really sure why your host can resolve hosts on your network but the OPNSense seems to be struggling there for you - I do know that I've found IPv6 to be skipped a fair amount by OPNSense Reverse and by some accounts even Forward resolution. To fix this, I setup my own BIND and have both IPv4 and IPv6 getting updated into it via both the DHCPv4 server and a Python script that scrapes all the sources of IP data and updates my BIND as necessary.

https://github.com/j0nny55555/homelabdnsupdater

Please feel free to detail a bit more about what is replying your host resolutions correctly inside your network (is it the OPNSense, or something else?), and remember, you can dig/drill @ip_address so you can specify who you ask about a local DNS resolution...

Code Select Expand

drill myhost.homelab.home AAAA @ns02.homelab.home - Forward Lookup (specifically IPv6 - quad-A)

Code Select Expand

drill -x 192.168.0.12 @ns02.homelab.home - Reverse Lookup

if you use your own BIND, and have alias doing internal resolution, and also have Overrides setup for say Unbound...

then OPNSense will use Unbound's data for the hosts you have overridden, the rest will resolve via your BIND

this is both a curse and a gift, if you have infra that needs to come up on boot, you can have the OPNSense Unbound Overrides fill-in for those parts, then the rest will come up and be completely automated...

you can API the aliases... and I'll bet you can API to Unbound's settings but I have not explored that yet

Minor point, but your message both ports read 51280, the images clearly show the difference between your intent of 51820 and it using 51280 repeatedly, but your text message shows both ports as the same.

That said, I do not know how to fix this... mine is configured for 51820 and using 51820. Remove the plug-in do clean-up, reinstall?

One - IDS > IPS - mainly because detection is inherently fault prone, blocking needed traffic means issues

Two - Enabling IDS rules via Policies in OPNSense's Policy management is okay

Three - Suricata has its own rule management detail that is already and installed and can be switched to
Switching to Suricata-Update from OPNSense's Policy Based IDS/IPS Rule Management - Using Suricata-Update on OPNSense
Also created a Github repo for Suricata-Update Config Files to give some actual SIDs/Regex that I use in my suricata-update runs - note - this repo has an update that I'm still finalizing, ah the to-do lists. The update isn't too major, just more disable, possibly one or two enable items and some modify rules that fix rule text issues I've found.

Four - There are likely bots/script-kiddies and zero if any VERY Unlikely APTs that are interacting with your IP. Blocking the script kiddies/inventory-the-internet traffic 'could' lighten the network load.

Five - Doing this without some level of data lake is not for the faint of heart, and data lakes aren't necessarily easy either but can work for focused searches / pattern checking. Graylog/Elastic/etc. can all be great places to send your syslogs (firewall/system/suricata) so you know about what's going on and if a rule modification is going to focus your IDS/environment more.

Six - This is really useful if you are actually hosting services, if there isn't anything being port forwarded into your network, then your IDS events will be few if any and mostly generated by your users. Most of the local user traffic based rules are extremely fault prone and of honestly little use. Enabling any Nginx/Apache/PHP/Wordpress/MySQL/Mariadb rules if you have a web host is easily a good idea.

Seven - The completeness number, neat. Encryption is a thing, and SSL/TLS/Encrypted traffic is of little use for IDS inspection, it won't be able to 'read' any other otherwise protocol/app level text/packet detail. If you are terminating the TLS for your hosted services using your Reverse Proxy in some DMZ zone and one or more Web Hosts in some Core zone, and have the proper setup (Reverse Proxy/Web Host/IDS) with XFF and as mentioned the back end services which must be set apart in a different interface/subnet/zone of your OPNSense, now you can read attacks inbound to your otherwise secure hosted Web Site(s) as the IDS can actually see it in the 'decrypted' traffic between the Reverse Proxy and the Web Host and inspect it. Your users' outbound/browsing activity is the hardest one to access, and requires you setup an internal CA PKI and install the Certs on your devices and setup it upon the Suricata... and it will eat your CPU alive I bet. Haven't done it, yet, might not ever lol.

If you are filtering/securing DNS, having IDS notice what is actually unwanted, have a Reverse Proxy in the mix, and using another OPNSense plug-in called CrowdSec, you can inspect your firewall logs and the Suricata logs to detect threats, and it will block them if they reach a threshold and then you can actually provide some level of 'corporate level network protection' for your network (Lite-NG-Firewall/Responsive-IDS/WAF/DNS-Filtering). It can turn a Reverse Proxy into a reactive WAF of sorts, impressive stuff. The CrowdSec block can work for all of your integrated Multi-Server setup (Agents - Parsers/Blockers/Appsec) and everyone else that uses CrowdSec depending on how you set it up (stay an island / share w/community).

CrowdSec can be a task to install, especially if you start growing it to be a Multi-Server setup but to say it is easily a catalyst to change the otherwise 'only logged' activity from your IDS into responsive action would be an understatement. Similar to Fail2ban or AbuseIPDB, but quite a bit more.

If you are sending data to them, you get larger access to their Community blocklist, mine is sitting at about 40k known threat IPs (HTTP/SSH/bots/etc.).
About that setup: CrowdSec Multi-Server with OPNSense Router

Lastly, I did write up how to enable mostly useful rules in OPNSense's Policy Management UI - but would earnestly recommend learning about suricata-update and familiarizing yourself enough with FreeBSD and where the folders are to 'switch over' to doing it with Suricata's native tool.

Hmmm, there is the UPnP plug-in and when configured with the correct Outbound NAT feature, allows most all Consoles to get their desired NAT

It sounds like you are having trouble connecting from one to the other on the same network though... that might require the mDNS plugin, and/or, permissive firewall rules between your hosts?

Any firewall logs mentioning blocking one of the IPs in question?

Without a doubt I would recommend installing and setting up the OPNSense mDNS Repeater plugin (enable it on the interfaces needed) - most all IoT/TVs/Phones/etc use it to communicate with other devices on the local network.

Just released, open for testing, if you BIND with your OPNSense and Docker (w/Portainer), this might be of interest!

As I have ran my own internal BIND DNS setup for a while, and did not explore the built-in that OPNSense has (wanted to learn-it-all), and then wanted to resolve IPv6 for my network this became an eventual desire and then creation. It uses the OPNSense API as well as the Portainer API, then directly and securely interacts with BIND via TSIG.

Please feel free to check it out, comment, or even suggest how else one would do the same in a different way:

Homelab DNS Updater (Github)

After having implemented IPv6, there is a need to be able to update the DNS Servers in this list dynamically, and I do not want to be limited to the two DNS servers for each ISC DHCP entry (and I am not using 'Kea DHCP' yet)

It is great that we have eight fields to add DNS Servers to in the System -> Settings -> General area, but it seems you cannot update these elements via the API, can anyone point out how to do it, or would this be a feature request?

Further, just want to say thank you to whoever got the ARP and NDP lists to be available via API - that is amazing and has let me dynamically update my BIND from MAC <-> Hostname for IPv6 rather easily. Also, just want to say to the network-gurus inventing things, thank-goodness MACs for IPv6 == MACs for IPv4. <3

Haha! I had a few tabs open and apparently posted on the wrong thread - there was a post that detailed how to use ansible to start an OPNSense development environment. Was curious if that had matured or not, and by the git repo for that it would seem that is still a very useful way to get started in developing for OPNSense.

Git repo:
https://github.com/punktDe/vagrant-opnsense

There's a comment I made on the plugins pull but I thought I would share here too:
https://github.com/opnsense/plugins/pull/2945

It would possibly be even better to allow us to select which auto rules get created instead of having to accept all or none, but if in the CrowdSec plugin we could get this option that would be acceptable.

That said, my intent here is to keep all of the rest of the functionality - so, I want the two aliases to be kept up to date by the plugin - I want to create my own rule to use those aliases but do not want the 'auto rule' getting in the way as it isn't deployed where or how I would want it.

The default rule only blocks in as a source, and does not block as a destination. Might be paranoid, but, I prefer to not even reach out to the badness as well. Further, I have a few hosts that I do not want to filter the traffic this way for, and want to let them interact with the IPs if they are on the CrowdSec blocklist or not.

Certainly interested to hear feedback on the idea/methods to help build it/how to get started.

Thank you all for all you do, I'd like to help but am a little inexperienced to take such a large bite.

Yes this is an old thread, but a great one, thank you!

As I too have a Proxmox setup and am interested in branching out and growing more development experience.

Would there be any write-up or direction to more reading to know how to setup my own development space for OPNSense?

I will be making a blog entry about this eventually, but if you use Traefik as your reverse proxy, you can setup a TCP match for your plex.direct FQDN that Plex uses and allow a TLS passthrough that will finally show your remote availabilty as always Green

It is literally THIS ^ that causes the issue (and I have ran Nginx reverse proxy, got green, but it would fall off almost immediately.

I port forward 443 to 443, and 80 to 80 for the Traefik setup, and in Traefik if they are requesting my plex subdomain on 443 or 80 I forward them to 32400, and if they request the '*.*.plex.direct' fqdn, I have Traefik TCP (not HTTP) TLS passthrough (they are using their own Digicert SSL Cert) the connection to 32400 to the Plex server. ^_^

Huge thanks as always!!

Using:
VLANs and Multi-Interface LAN FW Group
DHCP ISC
Unbound
APCUPSD
Crowdsec
Suricata IDS
Wireguard VPN for Clients
NAT Inbound Port Forwarding
Outbound NAT Forwarding
UPnP
mDNS Repeater
IGMP Proxy

Extra:
DHCP -> Side BIND environment

Moded:
Suricata-update w/125k+ rules modified enabled in ~5 minutes
Crowdsec (only running Agent now, and parsing default and suricata eve logs too)

So you are doing port forwarding, and you also have a blocking rule present on at least the WAN (ideally also the LAN(s)). It might be the Crowdsec IPv4 & IPv6 rules the plugin installs, or you maybe made the Spamhaus block rules and the Alias to sync the list from their sources.

What you might not realize is happening is, the Port Forward happens BEFORE any firewall rule on the WAN, so, it will forward in and then block on the LAN (if you have your rules blocking there) and this means extra work.

You can block at WAN and not forward!!

Just enable the 'Source' on the Port Forward rule, and set the 'Inverse' option, select your Blocklist (you can make a new list and have it hold multiple other lists that are syncing so you just give yourself one complete list to add to things) and hit save.

Do this on your Outbound NAT as well, just more or less in reverse - do the 'Destination' + 'Inverse' + your Blocklist, enjoy!

See image in attachments to this post! Hope this has helped someone, and happy Routing! Note - I did modify the image to remove my Proxy's Internal IP - so the blank field with no IP in it is only that way because of that.