Recent posts

#1

26.7 Series / Re: Interfaces: Virtual IPs: S...

Last post by MK4L - Today at 09:06:34 AM

There is absolutely no need for this type of VIP

If you could give me direction where this happens inside BSD itself (the side-effect, you say), I will just call it a day.
I can never trust routing/firewalling decisions of OPNSense while using static routes.

#2

General Discussion / Device Monitor v2.1 – Hostwatc...

Last post by apg1959 - Today at 09:01:35 AM

Hi,

I'm running OPNsense 26.7.2_2 with Device Monitor v2.1.

I found an issue where multiple historical Hostwatch records for the same MAC address can cause Device Monitor to select an old IP/interface record instead of the current one.

Example

My Windows PC has:

MAC: 7c:83:34:b2:34:7c
Current IP: 192.168.20.111
Interface: igc1 / LAN

Device Monitor initially showed this device incorrectly as:

IP: 192.168.20.146
Interface: IGC1
Offline

I checked the Hostwatch database directly:

sqlite3 /var/db/hostwatch/hosts.db \
"SELECT interface_name, ip_address, ether_address, first_seen, last_seen, organization_name
FROM v_hosts
WHERE ether_address='7c:83:34:b2:34:7c';"

Hostwatch contained three records for the same MAC:

igc1  192.168.20.146  2026-08-15 03:04:46
igc0  192.168.20.146  2026-08-15 11:10:03
igc1  192.168.20.111  2026-08-19 06:06:49

The last record is the current/correct one.

I also confirmed Hostwatch itself was updating correctly. For example, its most recent records included:

7c:83:34:b2:34:7c  192.168.20.111  igc1  2026-08-19 06:08:51

So Hostwatch was not the problem.

Cause

I traced this to:

/usr/local/opnsense/scripts/OPNsense/DeviceMonitor/scan_network.py

The Hostwatch query currently retrieves all matching records:

SELECT
    interface_name,
    ip_address,
    ether_address,
    first_seen,
    last_seen,
    organization_name
FROM v_hosts
WHERE protocol = 'inet'
  AND ether_address NOT IN ('ff:ff:ff:ff:ff:ff', '00:00:00:00:00:00')
  AND ip_address NOT LIKE '169.254.%'
ORDER BY last_seen DESC

There is no deduplication by ether_address.

Device Monitor's own database uses the MAC address as the key:

mac TEXT PRIMARY KEY

Therefore, when multiple Hostwatch records exist for the same MAC, they are processed sequentially and can overwrite one another. In my case, the historical .146 record ended up being stored instead of the current .111 record.

This also affected the Online/Offline status because Device Monitor was evaluating the stale record's last_seen.

Test fix

I tested a local modification to the SQL query which selects only the newest last_seen record for each MAC address, with the Hostwatch id used as a tie-breaker.

After applying the change and running a full scan, Device Monitor immediately changed the affected PC to:

MAC:      7c:83:34:b2:34:7c
IP:        192.168.20.111
Interface: IGC1
Status:    ONLINE

The Device Monitor database then showed:

7c:83:34:b2:34:7c
192.168.20.111
IGC1
2026-08-19 06:18:58
is_active = 1

I subsequently restarted Device Monitor and confirmed the service restarted normally and the Devices page continues to show the correct IP/interface/status.

Suggested fix

I believe the Hostwatch query should deduplicate records by ether_address and select the record with the newest last_seen before passing the results to the Device Monitor database.

This would prevent historical Hostwatch records from overwriting the current record for the same MAC.

The email notification functionality otherwise works correctly for me. I have successfully tested detection of a new MAC address and received the Device Monitor email notification through Postfix.

Thanks — I've attached modified SQL/query if useful.

#3

Tutorials and FAQs / Re: new to OpenSense and like ...

Last post by viragomann - Today at 08:50:55 AM

But you should be able to export CA and private keys as well as other X509 certificates from pfSense and import them into OPNsense then.

#4

Intrusion Detection and Prevention / Re: Policy Editor?

Last post by patient0 - Today at 08:50:54 AM

Coming back to this. Does anyone know how to do policies?

Can you provide a screenshot? That wording doesn't ring a bell at all. What phone and browser on the phone are you using?

[Goal]

#5

General Discussion / Re: Can I create locked down w...

Last post by Frank886t - Today at 08:50:08 AM

(Feel free to move this elsewhere if there's a better category.)

Previous experience has shown than I tend to mess up when I try to experiment with my firewall and network, so I thought I'd ask if any of my ideas are possible first.

Goal:

I'm looking for a way to use an old android phone as a kiosk to an app hosted on my home server. Since it's so old, I don't want it to have any internet.

And then there's my smart tv. I want to put it on a network that can't talk to anything.

USB Dongle idea
If I attached a couple usb wireless cards to my OPNSense box, could I use them to create a wireless network that didn't allow any traffic except for my app?

Router Idea
If I linked a spare wireless router to the OPNSense box using one of the open ports, could I lock down everything attached to that port? (I'm 99% sure that is possible.)

Rules Per Device Idea
Could OPNSense make sure that all traffic from a specific device is only allowed for the app I want to expose? As in my old phone would connect to my wireless network, and then OPNSense would prevent any traffic from, online games or to, it except for the designated app. How would that work when the wireless router has to route the traffic?

Are there any other ways to implement my goals?

Any tips on what to search for? My searches so far haven't found anything good.

Thanks!

Your ideas are definitely possible, and OPNsense is actually a good fit for this. The easiest approach would probably be to create separate VLANs or use a dedicated router/AP connected to a specific OPNsense interface, then apply firewall rules to isolate those devices. You don't need to control traffic by app itself; instead, allow only the IP/ports your server app needs and block everything else. For the old phone kiosk, a separate WiFi network with no WAN access but access only to your home server would work well. Search terms like "OPNsense VLAN firewall rules", "OPNsense captive portal", and "network isolation" should help.

#6

26.7 Series / Re: Interfaces: Virtual IPs: S...

Last post by mimugmail - Today at 08:19:12 AM

Yes, this would also be of interest, to see what happens when type is Alias instead of Other

#7

Tutorials and FAQs / Re: new to OpenSense and like ...

Last post by Monviech (Cedrik) - Today at 07:53:21 AM

If you use one of these importers, this will happen:

https://github.com/opnsense/core/issues/10714

Pfsense and OPNsense are too different than a few years ago. You better start new or you will always have a partially broken setup.

[The only]

#8

26.7 Series / Re: Interfaces: Virtual IPs: S...

Last post by franco - Today at 07:32:44 AM

To be honest:

> Other
>
> Other type VIPs define additional IP addresses for use when
> ARP replies for the IP address are not required. The only
> function of adding an Other type VIP is making that address
> available in the NAT configuration drop-down selectors. This
> is convenient when the firewall has a public IP block routed
> to its WAN IP address, IP Alias, or a CARP VIP.

Just use a plain IP or alias in NAT, done?  There is absolutely no need for this type of VIP.

[Why "Other" Mode behaves this way in FreeBSD]

#9

26.7 Series / Re: Interfaces: Virtual IPs: S...

Last post by MK4L - Today at 04:44:09 AM

Sorry to be offtopic, but what happens in the OS when you add a Virtual IP with type other?? I never had a demand to even think about its reason.

You are actually spot on! I was hoping someone would explain, but I had to dig it myself, and Gemini, not DeepSeek, gave me a hint...

Why "Other" Mode behaves this way in FreeBSD
In FreeBSD, pf rules process packets before layer-2 ARP resolution or layer-3 routing lookup occurs.

Because an "Other" VIP exists strictly as a condition check in pf:

Plaintext
[ Incoming Packet ]
      │
      ▼
[ FreeBSD pf Engine ] ──► "Does destination match the Other VIP?"
      │                                                          │
      YES                                                  NO
      │                                                          │
[ Rewrite Packet Headers ]          [ Normal Routing / ARP ]
(Target host changed;                (Sent to actual physical IP)
real router bypassed)

The system never reaches the stage where it asks FreeBSD "Where is the MAC address for this IP?" for the real router. The pf match happens first, changing the packet's destination header and redirecting it elsewhere.


What you actually see in FreeBSD without NAT
If you run these diagnostic commands on FreeBSD while using an "Other" VIP without NAT:

Code Select Expand

Bash
# 1. Check interface aliases:
ifconfig
# Result: The "Other" VIP will NOT appear anywhere.

# 2. Check kernel routing table:
netstat -rn
# Result: No route or local loopback host route entry exists for that IP.

# 3. Check loaded pf filter rules:
pfctl -sr
# Result: Unless you explicitly wrote a custom firewall Pass/Block rule matching
# that specific IP string, it will not appear anywhere in pf's rule memory.
Why do you see entries in pfctl -ss then?
The state table (pfctl -ss) tracks active packet flows passing through the pf module.

If you see an IP listed in pfctl -ss on a non-NAT system, pf is simply logging that a routed packet passed through OPNSense with that IP address in its original IP header (as either the source or destination) from an upstream or downstream host. pf creates a state entry to allow returning reply traffic, but FreeBSD itself is taking no action on the IP address other than basic packet forwarding.

- I never had a chance to see what pfctl -ss says in my setup if I strip all Other VIPs, and use static routing instead. (maybe because OPNSense tends to block UI access on OPT1 if you follow their recommendations ;P)
- With Other VIPs in place, pfctl -ss shows Packet Filter routing all packets where my routers want them to go. No touching.
- I still have no clue where the entries in pfctl -ss come from! /tmp/rules.debug does not have them.
- I must use this setup because I must never be ROUTING in all 3 "routers" directly connected to each other. Only REAL routers should do routing! (this is the anti-rant, you see!)
- To top it up, routing in BSD is cranky.

P.S: pfSense still uses VIP=Other. I just hate the UI of pfSense.

#10

Hardware and Performance / Re: Warning about RealTek adap...

Last post by moonman - Today at 01:14:52 AM

RTL8126 is very solid to me in Windows. There is some CPU utilization but that could be come in part from SMB too. And I paid 30 bugs for two cards. Feels like a no-brainer.

5Gbit/s isn't 10 though...