Sensei on OPNsense - Application based filtering

[Mks]

Hi,

thanks for the feedback.
I'm already in contact with the Sensei support and its as you described an issue with netmap.

I switched back to the VLAN Interfaces.

br

[Mitheor]

Hi all,

in your Sensei, is the name resolution working properly?

In my case it´s not in the reports page (realtime sessions works because the IPs are resolved in that moment).



As you can see i´m not seeing the names even though i´ve sent some queries for those machine names a few times minutes before and they are seen in the Sensei DNS tab, so, as far as i understand, those names should be cached and shown in the reports.

Am i right? Or what am i missing here?

[mb]

After some testing, it appears it is working as it should. All of the blocks were specific to the App Controls. It gives the option to whitelist the host, but that is whitelisting the host address for the Web Controls rather than App Controls. I know it is possible to drill down into the categories and unblock entire sub-categories, but it would be nice to have more control as we do with whitelists.

There was mention of a new release (1.5) on the horizon. Will there be a way to whitelist for App Filtering, or will hosts listed in Web Filtering take precedence over App Control?

Loving the premium features of this plugin, and looking forward to further development and features.

Hi @m1ke486837,

Thanks for your positive feedback. Yes, as you put it, With 1.4, app control takes precedence so whitelisting does not apply to App Controls.

We've improved this behavior with 1.5. With that, App Controls also takes whitelists into account.

You won't need to write seperate rules for App Controls. The ones on Web Controls will also work for it.

[mb]

As you can see i´m not seeing the names even though i´ve sent some queries for those machine names a few times minutes before and they are seen in the Sensei DNS tab, so, as far as i understand, those names should be cached and shown in the reports.

Hi @Mitheor,

For Sensei to be able to do proper DNS enrichment, it needs to be able to witness all dns transactions. If it does not work as it should it's generally:

https://help.sunnyvalley.io/hc/en-us/articles/360025100613-FAQ. See the section: "I do not see dns hostnames for some IP addresses"

One other thing which might play a role here is if you use a DNS cache in your local network which reside on some other host other than the firewall (on which Sensei is running), this will also cause some mappings going out of sight for Sensei - since those cached dns traffic will NOT be traversing through the firewall.

For those scenarios, (like Pihole) we suggest to disable caching on them and use firewall's dns cache as the forwarder.

If none of these is the case for you, just shoot a report via "Report Bug" menu located on the upper right hand corner of the UI.

[mb]

@l0rdraiden, thanks for the pointer. We'll have a look at these.

@donatom3, thanks for the hint.

@Mks, glad to hear that donatom3's hint also worked for you.

We hope to kill all netmap(4) related issues soon. Additionally we hope to bring netmap(4) support for lagg(4), bridge(4) and tun(4) based interfaces.

For that we might need some help in re-producing the bugs for the developers; and testing the fixes. I'll create a dedicated thread about this later this month.

[Mitheor]

As you can see i´m not seeing the names even though i´ve sent some queries for those machine names a few times minutes before and they are seen in the Sensei DNS tab, so, as far as i understand, those names should be cached and shown in the reports.

Hi @Mitheor,

For Sensei to be able to do proper DNS enrichment, it needs to be able to witness all dns transactions. If it does not work as it should it's generally:

https://help.sunnyvalley.io/hc/en-us/articles/360025100613-FAQ. See the section: "I do not see dns hostnames for some IP addresses"

One other thing which might play a role here is if you use a DNS cache in your local network which reside on some other host other than the firewall (on which Sensei is running), this will also cause some mappings going out of sight for Sensei - since those cached dns traffic will NOT be traversing through the firewall.

For those scenarios, (like Pihole) we suggest to disable caching on them and use firewall's dns cache as the forwarder.

If none of these is the case for you, just shoot a report via "Report Bug" menu located on the upper right hand corner of the UI.

Thanks for the reply.

I don't think it's the case because I can see those dns queries for these hosts en the Sensei DNS session browser 🤷🏻‍♂️

[mb]

I don't think it's the case because I can see those dns queries for these hosts en the Sensei DNS session browser 🤷🏻‍♂️

Hi @Mitheor, got it. Send a PR and we'll look closer into that.

[packetmangler]

As you can see i´m not seeing the names even though i´ve sent some queries for those machine names a few times minutes before and they are seen in the Sensei DNS tab, so, as far as i understand, those names should be cached and shown in the reports.

Hi @Mitheor,

For Sensei to be able to do proper DNS enrichment, it needs to be able to witness all dns transactions. If it does not work as it should it's generally:

https://help.sunnyvalley.io/hc/en-us/articles/360025100613-FAQ. See the section: "I do not see dns hostnames for some IP addresses"

One other thing which might play a role here is if you use a DNS cache in your local network which reside on some other host other than the firewall (on which Sensei is running), this will also cause some mappings going out of sight for Sensei - since those cached dns traffic will NOT be traversing through the firewall.

For those scenarios, (like Pihole) we suggest to disable caching on them and use firewall's dns cache as the forwarder.

If none of these is the case for you, just shoot a report via "Report Bug" menu located on the upper right hand corner of the UI.

I have this issue as well since I run multiple pi-holes and an internal authoritative bind server, but I've ignored it for the most part. 

If the DNS records are updated when requests pass through the firewall, would something as simple as having the firewall run through a list of reverse IP addresses and performing lookups on them work?

EDIT: I'm doing forward and reverse lookups on the firewall for all addresses on my local network and it appears that the graphs are indeed populating with host names where IP addresses were earlier.  So now the question is how often should that run?

[Callahan]

I'd like to chime in with the same question and an additional question (plus a small cosmetic bug report at the end).

Question one
To give you specifics in the hope that it helps give you/me a better understanding of what is going wrong (or more likely what I'm missing), my setup is as follows:

• OPNSense running on an i5 NUC with 8GB RAM.
• 1 LAN subnet of 192.168.100.0/24 which is attached to the physical LAN in OPNSense.
• 1 DMZ subnet (192.168.50.0/24), which is a virtual interface (VLAN) hanging off the LAN interface of OPNSense.
• 1 Proxy server on the DMZ.
• 1 Guest network (192.168.150.0/24), which is a virtual interface (VLAN) also hanging off the LAN interface of OPNSense.
• 1 WAN interface using PPoE to a DSL modem.
• A Windows domain of around 10 Windows servers and multiple Linux servers with 2 Windows DNS servers sitting at 192.168.100.14 & 192.168.100.15.
• A Pihole running on the same subnet (192.168.100.18).
• Both Windows DNS servers have the Pihole set as their forwarder.
• DHCP is handled by the same Windows servers that handle DNS queries.
• OPNSense is set up as a DHCP relay for both the Guest and LAN subnets.
• Windows DHCP is set up to always update DNS so I can see all of the hosts, regardless of type, are being registered in DNS.
• DNS query route goes: Client --> Windows DNS --> Pihole --> Internet.

I've installed Sensei today and also added the DNS servers (192.168.100.14 & 192.168.100.15), under: Sensei/Configuration/Reporting & Data with the expectation that Sensei would check DNS for the hostnames of the IPs that are hitting the LAN interface. This doesn't appear to be happening and I'm not clear on why that is.
Further testing shows that if I use the FW to do DNS then I see the hostnames.

Is the only solution to this setup, to set the DNS in my DHCP scopes as the firewall then set the forwarder on the firewall DNS to be my Windows DNS servers (to keep the domain working), then the forwarder on the Windows DNS servers to be my Pihole docker container? That seems an overly excessive amount of DNS queries but it's the only way I'm seeing this working. This would be a pretty standard setup in most orgs in the sense that the first DNS host they query will always be the Windows DNS servers on the domain.

If this is the solution, then I don't understand why the option to allow the reverse lookup of IPs is present in Sensei.

Question 2
I am looking at the reports for "Top Remote Hosts" and I am seeing entries in there as FQDNs that are my internal hosts on the 192.168.100.0/24 subnet. Definitely not remote hosts. Interestingly, as Sensei is reporting the FQDN, it has to be getting that from my Windows DNS servers (I'm running split DNS so my domain is resolved internally), so it is able to query my DNS servers and retreive local addresses. Surely it should know that if the resolved address sits on a range that it knows it hosts on the LAN interface, it isn't remote. I'd almost accept it if the address was on my DMZ but even then, the DMZ (in my specific case here), is a virtual interface of the LAN so again, easy to spot that it's not Remote.
Or maybe I'm misunderstanding your meaning of "remote".  :)

Last question/bug report
Go to Sensei/Configuration/Reporting & Data
Click the small orange "i" next to: "Perform health check for indices:" and you'll see that the help section for "Connection Security" and the section for "Reporting Criteria" in the block below opens up with the explanation for setting the Reporting Criteria for the email reports. The same thing happens if you click the orange "i" for "You can erase reporting data:"

Sorry for the overly long post, thanks for making it this far! I look forward to any insight you can offer to the above questions.

Thanks.

[Callahan]

I had another suggestion/possible feature request. I build a fair number of dashboards using an Elasticstack cluster at work and noticed that you use the map to locate traffic destinations. I'm assuming you make use of the same DB that OPNSense does if you use the GeoIP alias (GeoLite2-Country-CSV)? I use the same setup for plotting traffic destinations at work except I use the GeoLite2-City-CSV. As you allow for the zooming in on the traffic map, might it be a suggestion to use a city IP locator instead of a country one? The map would look far more impressive if it split out the destinations into cities. At the moment, all my traffic bound for the US is ending up in Cheney Reservoir in Wichita!  ;)

[l0rdraiden]

I'd like to chime in with the same question and an additional question (plus a small cosmetic bug report at the end).

Question one
To give you specifics in the hope that it helps give you/me a better understanding of what is going wrong (or more likely what I'm missing), my setup is as follows:

• OPNSense running on an i5 NUC with 8GB RAM.
• 1 LAN subnet of 192.168.100.0/24 which is attached to the physical LAN in OPNSense.
• 1 DMZ subnet (192.168.50.0/24), which is a virtual interface (VLAN) hanging off the LAN interface of OPNSense.
• 1 Proxy server on the DMZ.
• 1 Guest network (192.168.150.0/24), which is a virtual interface (VLAN) also hanging off the LAN interface of OPNSense.
• 1 WAN interface using PPoE to a DSL modem.
• A Windows domain of around 10 Windows servers and multiple Linux servers with 2 Windows DNS servers sitting at 192.168.100.14 & 192.168.100.15.
• A Pihole running on the same subnet (192.168.100.18).
• Both Windows DNS servers have the Pihole set as their forwarder.
• DHCP is handled by the same Windows servers that handle DNS queries.
• OPNSense is set up as a DHCP relay for both the Guest and LAN subnets.
• Windows DHCP is set up to always update DNS so I can see all of the hosts, regardless of type, are being registered in DNS.
• DNS query route goes: Client --> Windows DNS --> Pihole --> Internet.

I've installed Sensei today and also added the DNS servers (192.168.100.14 & 192.168.100.15), under: Sensei/Configuration/Reporting & Data with the expectation that Sensei would check DNS for the hostnames of the IPs that are hitting the LAN interface. This doesn't appear to be happening and I'm not clear on why that is.
Further testing shows that if I use the FW to do DNS then I see the hostnames.

Is the only solution to this setup, to set the DNS in my DHCP scopes as the firewall then set the forwarder on the firewall DNS to be my Windows DNS servers (to keep the domain working), then the forwarder on the Windows DNS servers to be my Pihole docker container? That seems an overly excessive amount of DNS queries but it's the only way I'm seeing this working. This would be a pretty standard setup in most orgs in the sense that the first DNS host they query will always be the Windows DNS servers on the domain.

If this is the solution, then I don't understand why the option to allow the reverse lookup of IPs is present in Sensei.

Question 2
I am looking at the reports for "Top Remote Hosts" and I am seeing entries in there as FQDNs that are my internal hosts on the 192.168.100.0/24 subnet. Definitely not remote hosts. Interestingly, as Sensei is reporting the FQDN, it has to be getting that from my Windows DNS servers (I'm running split DNS so my domain is resolved internally), so it is able to query my DNS servers and retreive local addresses. Surely it should know that if the resolved address sits on a range that it knows it hosts on the LAN interface, it isn't remote. I'd almost accept it if the address was on my DMZ but even then, the DMZ (in my specific case here), is a virtual interface of the LAN so again, easy to spot that it's not Remote.
Or maybe I'm misunderstanding your meaning of "remote".  :)

Last question/bug report
Go to Sensei/Configuration/Reporting & Data
Click the small orange "i" next to: "Perform health check for indices:" and you'll see that the help section for "Connection Security" and the section for "Reporting Criteria" in the block below opens up with the explanation for setting the Reporting Criteria for the email reports. The same thing happens if you click the orange "i" for "You can erase reporting data:"

Sorry for the overly long post, thanks for making it this far! I look forward to any insight you can offer to the above questions.

Thanks.

The only clean solution would be to feed pihole or adguard home logs into logstash so it can be displayed by sensei. Maybe with the API's something can be done.
https://github.com/AdguardTeam/AdGuardHome/tree/master/openapi

Or doing exactly this

Pi-hole data visualization using Elasticsearch, Logstash and Kibana
https://github.com/nin9s/elk-hole

[l0rdraiden]

https://www.sunnyvalley.io/post/sensei-for-opnsense-1-5-released/

[mb]

EDIT: I'm doing forward and reverse lookups on the firewall for all addresses on my local network and it appears that the graphs are indeed populating with host names where IP addresses were earlier.  So now the question is how often should that run?

Hi @packetmangler,

With release 1.5, cache time to live is 8 hours. (higher with 1.4) So, could be every 6 hours so that it replenishes the cache.

[mb]

Hi @Callahan,

Thanks for taking the time and sharing your thoughts. Much appreciated.

Correction & suggestion well noted.

For IP <-> Hostname mapping, please see this FAQ entry:
https://help.sunnyvalley.io/hc/en-us/articles/360025100613-FAQ#h_023043d9-df52-46e7-a7f6-cded4bf8f697

As for some hosts being reported as "Remote": Yes, there's some philosophy here:)

Sensei runs on inner-facing interfaces and determines the "remote" / "local" properties in terms of where the connection is initiated. If it comes from the LAN side, than the src ip address is considered local and dst ip address is regarded as "remote".

So if a connection is from a local host behind network A to a host behind local network B, sensei will consider the host on local network B as "remote", since for the context of the connection, it was the "remote end".

Obviously this is creating a bit confusion. Let us give this a bit of thought.

[mb]

https://www.sunnyvalley.io/post/sensei-for-opnsense-1-5-released/

Hi @l0rdraiden, thanks for the post.

Yes, Sensei for OPNsense Release 1.5 is available for update/installation.

Enjoy and stay safe
Sensei team