"Recent posts
#1
General Discussion / Re: Allow Public Internet IPv4...
Last post by Patrick M. Hausen - Today at 04:39:01 PMWhy are people all of a sudden using the exact same overspecific template to ask simple questions on this forum? I'm tired of reading through all this nonsense and might not provide answers anymore. Hint: this is not helpful.
"How can I allow a particular local network Internet access without using destination 'any' while blocking access to other local networks?"
Would have been much much better and entirely sufficient.
"How can I allow a particular local network Internet access without using destination 'any' while blocking access to other local networks?"
Would have been much much better and entirely sufficient.
#2
Documentation and Translation / DROP firewall rules
Last post by wiring8228 - Today at 04:24:02 PMI would suggest adding a new section to the OPNsense documentation under https://docs.opnsense.org/manual/how-tos/drop.html for the new default firewall rules.
The sections "Step 2 - Firewall Rules Inbound Traffic" and "Step 3 - Firewall Rules Outbound Traffic" currently do not appear to document the new rules that are now included by default (presumably since OPNsense 26.7).
In my case, I have configured it as follows using the new rules:
The sections "Step 2 - Firewall Rules Inbound Traffic" and "Step 3 - Firewall Rules Outbound Traffic" currently do not appear to document the new rules that are now included by default (presumably since OPNsense 26.7).
In my case, I have configured it as follows using the new rules:
- Enabled: ✅
- Categories: Threat Intelligence
- Description: Block Spamhaus DROP
- Interface: LAN, WAN
- Quick: ✅
- Action: Block
- Direction: In
- Version: any
- Protocol: any
- Source: Spamhaus_DROPv4, Spamhaus_DROPv6
- Source Port: any
- Destination: any
- Destination port: any
#3
General Discussion / Re: Minimum Supported Refresh ...
Last post by MoonbeamFrame - Today at 04:15:15 PMI only see the 'Last updated' column update when there has been a change to the data being downloaded.
#4
General Discussion / Re: Minimum Supported Refresh ...
Last post by wiring8228 - Today at 04:08:40 PMI checked the logs again and saw that the IP lists are being updated:
However, under Firewall > Aliases, the 'Last updated' column isn't being updated, even though the logs show that the update should have worked.
Is this a bug, or am I misunderstanding something?
Code Select
2026-08-08T15:17:02 Notice firewall processing alias url https://www.spamhaus.org/drop/drop_v6.json took 0.04s
2026-08-08T15:17:02 Notice firewall fetch alias url https://www.spamhaus.org/drop/drop_v6.json (bytes: 5915)
2026-08-08T15:07:04 Notice firewall processing alias url https://www.spamhaus.org/drop/drop_v4.json took 0.30s
2026-08-08T15:07:03 Notice firewall fetch alias url https://www.spamhaus.org/drop/drop_v4.json (bytes: 102911)
2026-08-08T14:16:26 Notice firewall processing alias url https://www.spamhaus.org/drop/drop_v6.json took 0.03s
2026-08-08T14:16:26 Notice firewall fetch alias url https://www.spamhaus.org/drop/drop_v6.json (bytes: 5915)
2026-08-08T14:06:57 Notice firewall processing alias url https://www.spamhaus.org/drop/drop_v4.json took 0.23s
2026-08-08T14:06:57 Notice firewall fetch alias url https://www.spamhaus.org/drop/drop_v4.json (bytes: 102911)However, under Firewall > Aliases, the 'Last updated' column isn't being updated, even though the logs show that the update should have worked.
Is this a bug, or am I misunderstanding something?
#5
General Discussion / Re: Allow Public Internet IPv4...
Last post by viragomann - Today at 04:03:42 PM"WAN network" is not the the internet, but it's just the Subnet defined on WAN interface. It's the equivalent to "LAN network".
To achieve internet only access, I create an alias and add all private network ranges to it, called it RFC1918.
Then I use this in the pass rule as destination with "Invert Destination" checked.
Then this rule permits access to non-RFC 1918 IPs only.
However, remember that this rule don't permit any access to local IPs. Hence you have to add additional rule to allow DNS, NTP, etc. on this interface.
To achieve internet only access, I create an alias and add all private network ranges to it, called it RFC1918.
Then I use this in the pass rule as destination with "Invert Destination" checked.
Then this rule permits access to non-RFC 1918 IPs only.
However, remember that this rule don't permit any access to local IPs. Hence you have to add additional rule to allow DNS, NTP, etc. on this interface.
#6
General Discussion / Allow Public Internet IPv4 Onl...
Last post by wiring8228 - Today at 03:32:37 PMProblem Description:
Internet connectivity works for all LAN clients when using the "Default allow LAN to any rule" in OPNsense.
However, I want to restrict LAN traffic so that clients can access only public Internet IPv4 addresses (e.g. Google) and cannot access the upstream/private networks or other internal VLANs.
I also suspect that the default LAN net → any rule allows LAN clients to access the other VLANs I have configured on OPNsense, which is not desired.
I want the LAN to have Internet access without granting unrestricted access to other internal networks/VLANs.
Expected Behavior:
LAN clients should be able to access all public Internet IPv4 addresses, including services such as Google, while being prevented from accessing private/internal IPv4 networks and other VLANs.
I would also prefer not to rely on multiple explicit block rules for private networks, as this was not necessary in my previous setup with Sophos UTM, where a single rule from LAN to an object like "Internet IPv4" was sufficient to achieve the same behavior.
Actual Behavior:
With the default:
Interface: LAN
Action: Pass
Direction: In
Version: IPv4
Protocol: any
Source: LAN network
Source Port: any
Destination: any
Destination Port: any
LAN clients have full internet access.
However, when changing the configuration to:
Interface: LAN
Action: Pass
Direction: In
Version: IPv4
Protocol: any
Source: LAN network
Source Port: any
Destination: WAN network
Destination Port: any
LAN clients no longer have internet access.
I suspect this is because the destination "WAN network" refers only to the directly connected 192.168.2.0/24 network rather than the public Internet.
Relevant System Information:
OPNsense 26.7.1
Network Topology:
├── Upstream Device: tp-link Archer MR200
│ └── IP: 192.168.2.1
├── OPNsense WAN Interface
│ ├── IP: 192.168.2.2/24 (Static)
│ └── Gateway: 192.168.2.1
├── OPNsense LAN Interface
└── IP: 192.168.10.1/24
Question:
What is the correct way to configure the OPNsense firewall so that:
Would the recommended approach be to create explicit block rules for the private networks and other VLAN networks, followed by an allow rule for Internet traffic?
Or could Invert Destination be used to achieve this? I don't fully understand how this option works in this context.
For example, would setting:
Destination: WAN network
Invert Destination: enabled
effectively mean "allow traffic to any destination except the WAN network"?
Internet connectivity works for all LAN clients when using the "Default allow LAN to any rule" in OPNsense.
However, I want to restrict LAN traffic so that clients can access only public Internet IPv4 addresses (e.g. Google) and cannot access the upstream/private networks or other internal VLANs.
I also suspect that the default LAN net → any rule allows LAN clients to access the other VLANs I have configured on OPNsense, which is not desired.
I want the LAN to have Internet access without granting unrestricted access to other internal networks/VLANs.
Expected Behavior:
LAN clients should be able to access all public Internet IPv4 addresses, including services such as Google, while being prevented from accessing private/internal IPv4 networks and other VLANs.
I would also prefer not to rely on multiple explicit block rules for private networks, as this was not necessary in my previous setup with Sophos UTM, where a single rule from LAN to an object like "Internet IPv4" was sufficient to achieve the same behavior.
Actual Behavior:
With the default:
Interface: LAN
Action: Pass
Direction: In
Version: IPv4
Protocol: any
Source: LAN network
Source Port: any
Destination: any
Destination Port: any
LAN clients have full internet access.
However, when changing the configuration to:
Interface: LAN
Action: Pass
Direction: In
Version: IPv4
Protocol: any
Source: LAN network
Source Port: any
Destination: WAN network
Destination Port: any
LAN clients no longer have internet access.
I suspect this is because the destination "WAN network" refers only to the directly connected 192.168.2.0/24 network rather than the public Internet.
Relevant System Information:
OPNsense 26.7.1
Network Topology:
├── Upstream Device: tp-link Archer MR200
│ └── IP: 192.168.2.1
├── OPNsense WAN Interface
│ ├── IP: 192.168.2.2/24 (Static)
│ └── Gateway: 192.168.2.1
├── OPNsense LAN Interface
└── IP: 192.168.10.1/24
Question:
What is the correct way to configure the OPNsense firewall so that:
- LAN clients can access all public IPv4 addresses on the Internet.
- LAN clients cannot access other private IPv4 networks (in my case VLANs) besides manually specified ones.
- Internet access does not depend on using Destination: any.
Would the recommended approach be to create explicit block rules for the private networks and other VLAN networks, followed by an allow rule for Internet traffic?
Or could Invert Destination be used to achieve this? I don't fully understand how this option works in this context.
For example, would setting:
Destination: WAN network
Invert Destination: enabled
effectively mean "allow traffic to any destination except the WAN network"?
#7
General Discussion / Re: nfSensei ( fork pfsense )
Last post by pfry - Today at 03:06:56 PMQuote from: Nullman on Today at 02:13:03 PMIt will support VPP, and thats something that BSDs dont have.
It's not exactly turnkey, but it can be compiled with both netmap and DPDK. VPP seems to be in a perpetual alpha/beta state.
#8
General Discussion / Re: nfSensei ( fork pfsense )
Last post by Melroy vd Berg - Today at 02:35:48 PMQuote from: Stormscape on Today at 09:40:09 AMThe obviously AI generated logo I admit doesn't inspire much confidence in the project.
The logo? No the WHOLE site is AI generated if you can't tell.
#9
General Discussion / Re: nfSensei ( fork pfsense )
Last post by nero355 - Today at 02:21:28 PMQuote from: Nullman on Today at 02:13:03 PMIt will support VPP, and thats something that BSDs dont have.https://s3-docs.fd.io/vpp/26.10/
That sounds interesting!
/Needs more reading :)
#10
Q-Feeds (Threat intelligence) / Help fixing 'erroneous' Q-Feed...
Last post by Taunt9930 - Today at 02:17:29 PMHi All,
I am not sure if this is a Q-feeds issue, OPNSense Firewall Issue, or a me issue.
After working for some time, I noticed the other day that my Aqara presence sensors can no longer be controlled by the Aqara app. Upon looking at the OPNSense firewall live log, it appears that connections from those devices into the firewall/out to the internet is suddenly being blocked by my Qfeeds rule blocking connections to the qfeeds created malware-ip feed.
EDIT: The event is also shown in the Qfeeds events pane.
When I search for the IP on the TIP, nothing comes up - no IOC's.
This (happily) appears to be the only connection being blocked by this rule - connection to this IP from the two Aqara Device IP's.
EDIT: If I go to firewall > Diagnostics > aliases and select the qfeeds malware alias in the dropdown, and search for the IP, it does not appear to be in the list. Why is it being blocked? What can I do to work out why this is suddenly being blocked. If I disable the qfeeds rule, all is well.
The IP in question is 43.131.7.8
Thanks - I appreciate any help anyone can give!
I am not sure if this is a Q-feeds issue, OPNSense Firewall Issue, or a me issue.
After working for some time, I noticed the other day that my Aqara presence sensors can no longer be controlled by the Aqara app. Upon looking at the OPNSense firewall live log, it appears that connections from those devices into the firewall/out to the internet is suddenly being blocked by my Qfeeds rule blocking connections to the qfeeds created malware-ip feed.
EDIT: The event is also shown in the Qfeeds events pane.
When I search for the IP on the TIP, nothing comes up - no IOC's.
This (happily) appears to be the only connection being blocked by this rule - connection to this IP from the two Aqara Device IP's.
EDIT: If I go to firewall > Diagnostics > aliases and select the qfeeds malware alias in the dropdown, and search for the IP, it does not appear to be in the list. Why is it being blocked? What can I do to work out why this is suddenly being blocked. If I disable the qfeeds rule, all is well.
The IP in question is 43.131.7.8
Thanks - I appreciate any help anyone can give!
