Messages

The problem with null routing is that it breaks policy based site-to-site VPNs

If you are able to reconfigure your IPSEC policy based VPN's to use VTI's, you may overcome the discarded packets.

If anyone on this list has used the 'return' or 'return-icmp' option in their pf firewall rules for ICMP packets, they may be able to advise which versions of OPNsense / FreeBSD it was known to work in.

You could file a bug report with FreeBSD.

[Update] Alternatively, you may be able to set up a UDP ping between the hosts and react on the responses received.

It appears to be a pf issue. I don't have a convenient way to test UDP (e.g. traceroute, where the application will report unreachables clearly), but TCP returns RST. I'm too lazy to run a capture. ICMP, as you noted, appears to return nothing. I do not know offhand if the "blackhole" sysctls affect this, as I have them... unholed; I don't see an ICMP sysctl offhand that would affect unreachables (other than net.inet.icmp.icmplim).

A search turned up a couple forum posts on the issue (other than this forum); I didn't try to dig into bug reports.

Edit: Ha! lmoore's post - I use bridges, so that appears to be my issue at least. Interesting.

I stand corrected with my assertion about this not being in PF.

I found an old IPF ruleset which included;

block return-icmp(host-prohib) in quick proto icmp all icmp-type echo group 210

Applying this to pf on an OpenBSD boxen as;

block return-icmp(host-prohib) in quick inet proto icmp all icmp-type echoreq

We see the expected reply.

00:22:30.237183 10.200.128.22 > 10.200.128.20: icmp: echo request
00:22:30.237271 10.200.128.20 > 10.200.128.22: icmp: host 10.200.128.20 unreachable - admin prohibited
00:22:31.245814 10.200.128.22 > 10.200.128.20: icmp: echo request
00:22:31.245863 10.200.128.20 > 10.200.128.22: icmp: host 10.200.128.20 unreachable - admin prohibited
00:22:32.245857 10.200.128.22 > 10.200.128.20: icmp: echo request
00:22:32.245904 10.200.128.20 > 10.200.128.22: icmp: host 10.200.128.20 unreachable - admin prohibited

Changing the rule to;

block return in quick inet proto icmp all icmp-type echoreq

00:25:40.316392 10.200.128.22 > 10.200.128.20: icmp: echo request
00:25:40.316483 10.200.128.20 > 10.200.128.22: icmp: 10.200.128.20 protocol 1 port 15632 unreachable
00:25:41.325803 10.200.128.22 > 10.200.128.20: icmp: echo request
00:25:41.325888 10.200.128.20 > 10.200.128.22: icmp: 10.200.128.20 protocol 1 port 28145 unreachable
00:25:42.325833 10.200.128.22 > 10.200.128.20: icmp: echo request
00:25:42.325922 10.200.128.20 > 10.200.128.22: icmp: 10.200.128.20 protocol 1 port 10076 unreachable

In OPNsense the rule appears as;

block return in log quick inet proto icmp all icmp-type echoreq label "<id>"

tcpdump does not show any form of reply.

A little more digging around and testing is required.

I have a HDD with FreeBSD 15.1 installed on it. It will be interesting to see how it behaves.

[Edit] The same is observed with a generic installation of FreeBSD 15.1 - seems like an upstream issue.

Rule:
@1 block return-icmp(host-prohib) in log quick inet proto icmp all icmp-type echoreq
pflog:
2026-09-18 02:14:51.779906 rule 1/0(match): block in on em0: 10.200.128.22 > 10.200.128.2: ICMP echo request, id 18879, seq 0, length 64
2026-09-18 02:14:52.785960 rule 1/0(match): block in on em0: 10.200.128.22 > 10.200.128.2: ICMP echo request, id 18879, seq 1, length 64
2026-09-18 02:14:53.785920 rule 1/0(match): block in on em0: 10.200.128.22 > 10.200.128.2: ICMP echo request, id 18879, seq 2, length 64

tcpdump:
02:16:23.919342 IP 10.200.128.22 > 10.200.128.2: ICMP echo request, id 53324, seq 0, length 64
02:16:24.925840 IP 10.200.128.22 > 10.200.128.2: ICMP echo request, id 53324, seq 1, length 64
02:16:25.925842 IP 10.200.128.22 > 10.200.128.2: ICMP echo request, id 53324, seq 2, length 64

But changing the rule from "REJECT" to "BLOCK", either incoming on lan or outgoing on WAN does not give me an icmp-reply

man page for pf.conf(5) - https://man.freebsd.org/cgi/man.cgi?query=pf.conf&apropos=0&sektion=0&manpath=FreeBSD+15.1-RELEASE+and+Ports.quarterly&format=html#PACKET_FILTERING

My understanding off a reject rule is,  that it will send an icmp administrative Prohibit, or similar.

Here is the information in the OPNsense documentation - https://docs.opnsense.org/manual/firewall.html#action

May be you're thinking of IPF as I recall using it at the turn of the century for ping requests arriving from the Internet. I don't believe PF ever could and I can't say I ever missed it after transitioning. Even back then, the best approach was to simply block such connections. At least your REJECT rule will let TCP & UDP connections know they are not welcome. When a reject rule is logged, it is recorded as blocked.

As @nero355 has suggested, you would use Null Routes to sink traffic to RFC-1918 addresses not known by your firewall - see https://forum.opnsense.org/index.php?msg=259031

I've not surrendered any options yet - so I might still..

If you decide to restore your configuration using OPNsense 25.1, the notes I've attached will hopefully guide you through a smooth restore and upgrade.

When I performed the restore, I used a configuration file created just after midnight on the 28th of January 2022, prior to installing 22.1 a few days later.

Thank you for your efforts.

I've just updated my production firewall and all is working as expected.

Cheers,

Larry.

As long as your device has internet access, it can spy on you even when it cannot reach its neighbors one way or another. As the video shows, the webcams and microphones are accessible from outside.

I don't have a Smart TV for privacy reasons. However, any device used to stream content from the Internet can send telemetry.

Reading this article, NTP is also utilised for gathering information.

I've included a Destination NAT rule to redirect NTP connections to OPNsense.

If you really want to get away from it all you need to be a lot more radical and go for something like https://plasma-bigscreen.org/

This could be an alternative.

# opnsense-patch https://github.com/opnsense/core/commit/050f3c8277

Thanks Franco.

Now working in both browsers.

Cheers,

Larry.

I was about to respond to the request for the call for Wireless testing of the new Wireless MVC/API when I noticed the update for 26.7.4 is now available.

On my test system I restored the configuration from my production firewall and then disabled the non-existent interfaces prior to applying the patch. Testing was successful.

I've now updated my test system to 26.7.4 and have noticed when scrolling up or down the list of firewall rules, the table jumps up and back resulting in flashing of the page - this is in FireFox 140.15.0esr

Testing with MS Edge, trying to drag the scroll bar down the page isn't successful - shortly after scrolling down, it jumps back up to the top of the page.

I've not observed the problem anywhere else (yet), not even when scrolling the Live View of the firewall logs.

It occurs in both opnsense and opnsense-dark themes.

Is anyone else experiencing this problem?

[Update] Maximising the grid in Firewall -> Rules allows scrolling to work normally in MS Edge & Firefox.

[Backup]

Good to hear you're making progress.

FWIW, I would have installed 25.1 on the Backup firewall and using the Web GUI on Backup firewall, restored the configuration file created on the Primary, also using the Web GUI.

If the restored configurations put the system in a functional state, one would be well on their way to having a firewall to drop in as a replacement.

However, with the path you are on I would suggest getting DHCP working on the Backup firewall using the OPNsense documentation before tackling the reservations you have.

OPNsense documentation:

- https://docs.opnsense.org/manual/dnsmasq.html

Here is a list (not exhaustive) of articles after searching migrating from ISC DHCP to Dnsmasq on OPNSense.

- https://www.bigiron.cc/guides/opnsense-dhcp-migration-isc-to-kea-or-dnsmasq
- https://learntohomelab.com/docs/HomeLab-Series/EP41_OPNsense%20ISC%20DHCP%20Migration%20to%20Dndsmasq%20DHCP/
- https://homenetworkguy.com/how-to/migrate-from-isc-dhcp-to-dnsmasq-or-kea-dhcp-in-opnsense/
- https://blog.hyperboly.net/posts/guides/isc-to-dnsmasq-opnsense/
- https://www.youtube.com/watch?v=AzJB6Mx3CnQ
- https://github.com/meyergru/iscdhcp_to_dnsmasq
- https://forum.opnsense.org/index.php?topic=51785.0
- https://forum.opnsense.org/index.php?topic=47371.0

[Backup]

I've hit a snag in setting up the "isolated network"

You have a DHCP server running in OPNsense on your LAN port, so you can't simply change the LAN IP address from the console whilst the DHCP server is running.

Isolated Netowrk:

Code Select Expand

        +-------------------+                       +-------------------+
        |     PC with       |                   LAN |     Backup        |
        |  Ethernet port    |<--------------------->|     OPNsense      |
        |  IP set manually  |    Ethernet Cable     |     Firewall      |
        | 192.168.1.254/24  |                       |  192.168.1.1/24   |
        | unless DHCP is    |                       |                   |
        |    working        |                       |                   |
        +-------------------+                       +-------------------+

I don't understand why you plugged the WAN port in to your functioning LAN - it wasn't going to work. That's why I advised disconnecting network cables.

What happened when you substituted the machines after restoring the configuration?

Working with the Backup machine and your PC, which are isolated from the rest of your network, plug a network cable into the Backup machine's LAN port and plug the other end into your PC's Ethernet port.

If you don't receive an IP address after a couple of minutes, manually configure TCP/IP on the PC and assign an unused IP address on your 192.168.1.0/24 network, such as 192.168.1.254/24, set the gateway and DNS server addresses to 192.168.1.1 .

If you are you able to ping 192.168.1.1 you should be able to access the Web GUI too.

If you have access to the Web GUI, plug your WAN cable from the Primary machine in to the WAN port of the Backup machine.

Let me know what is and isn't working at this point.

What are the interface names for LAN & WAN?

[isolated network]

4. [QUESTION] Do you know what the last version number was for OPNsense that had the ISC DHCP as the default configuration?

25.1 and earlier.

3. [QUESTION] Would the installation instructions I used for ver. 26.7 also work with older versions?

Yes, this seems to be a standard installation.

2. [COMMENT] After posting my question, I found a clear set of installation instructions for OPNsense. I successfully installed ver 26.7 on the "Backup" host machine.

I'm still using the Legacy ISC DHCP server on 26.7 and I've not had to make any changes to keep it running after upgrading. I will migrate to Kea down the track.

1. [QUESTION] I've only got a single network, and it's a fairly small one; ...  Would this setup be what you characterized as an "isolated network"??  If there's a simpler/better method, please let me know.

No. You may be able to apply your configuration when installing from media on the Backup machine, which may ease the change. Refer to the OPNsense Importer documentation to import a configuration file at installation time - https://docs.opnsense.org/manual/install.html#opnsense-importer

Here are some suggestions:

Primary machine:

Perform a configuration back-up including RRD data.

Copy the configuration file to the conf directory on a USB stick per the OPNsense Importer instructions.

Backup machine:

Download and prepare installation media for OPNsense 25.1 or earlier.

Consider using ZFS for the file system as using Snapshots is easy.

Disconnect network cables.

Ensure BIOS is configured for UEFI mode.

Installation Choices - YMMV

Boot the installation image and follow the steps;

 1) listed under For new installations or migrations, follow this process: in https://docs.opnsense.org/manual/install.html#opnsense-importer and then log in as installer to commit it to the Hard Drive.

 2) performed using https://opnsenselab.com/posts/opnsense-initial-setup-guide/



Substitute machines and test.

I'll iterate:

• Resolve plugin conflicts using the latest update of the first installed version of OPNsense, e.g. 25.1.12.
• Repeat the configuration back-up prior to each major version upgrade.
• When you get to 26.1.11, make sure you perform the firewall rules migration prior to upgrading to 26.7.
• If you get to version 26.7, ensure you update your Boot Loader - Refer to https://forum.opnsense.org/index.php?msg=271899

HTH - I think you're getting there.

The built-in blocklist tester returns:
{"status":"error"}

This is a clue to your problem. When operating normally it will report as "OK".

Review Unbound log file for problems.

The domain 'metrics.icloud.com' is reported as blocked on my system;

Code Select Expand

{
  "status": "OK",
  "action": "Block",
  "policy": {
    "source_nets": [],
    "address": "0.0.0.0",
    "rcode": 0,
    "description": "Hagezi Multi ULTIMATE - Agressive",
    "id": "cef05142-cb68-4a0f-91cb-af2383e450b4",
    "passlist": ".*localhost$",
    "prio": 3.402823669209385e+38,
    "hidx": 0,
    "bl": "ULTIMATE - Aggressive Blocking",
    "category": "Hagezi Multi - Clean the Internet"
  }
}

You may be able to install OPNsense 22.1 on your back up machine as it's still available to download from the mirrors.

Take a current back up of your SuperMicro Atom and remove the tick for 'Do not backup RRD data.' before downloading the configuration.



Set up the back up machine on an isolated network to avoid IP address conflicts with the installation on the back up machine and especially when you've restored the configuration file.

You may be able to restore this configuration in to the OPNsense 22.1 installation. If there are differences with the interfaces, you will be prompted to resolve them.

If the restored configuration looks good, swap out the Atom with the back up machine and verify functionality.

If you are able to install updates, install the last of the 22.1 series, which is 22.1.10.

Go to System -> Firmware -> Status. If there are any plugin conflicts, press the button to resolve them.

Perform another configuration back up remembering to remove the tick so your RRD data is backed up too.

Review the update notes prior to each update and if necessary, make appropriate changes after the update.

Repeat the configuration backup prior to each major version upgrade.

I don't recall any unexpected behaviour when I updated my system to 26.1. However, when you get to 26.1.11 make sure you perform the firewall rules migration prior to upgrading to 26.7.

If you get to version 26.7 ensure you update your Boot Loader - Refer to https://forum.opnsense.org/index.php?msg=271899

HTH :).

[Edit] Add note to check for plugin conflicts.

There are however a few popular youtube videos pushing that scenario, which I disapprove ;) .

After reading your comment, I did a search for articles relating to the set up of an OPNsense Transparent Firewall.

Of the few articles I viewed, written and videos, they all mentioned disabling the anti-lockout rules for the LAN interface. None of them addressed the initial installation of OPNsense.

If one desires using LAN & WAN descriptions for the bridge members, there is no need to disable the anti-lockout rules. All that is needed is to spend a couple of minutes more, either during the installation phase or at the end if the system is left to its own decisions to assign the interface, and to use the console (video or serial) to re-assign the interfaces per the steps earlier in this thread, including assigning the management IP address on the nominated interface.

The OPNsense anti-lockout rules will be assigned to the interface above which had the IP address assigned to it, therefore there is no need to create new rules to access the management interface. Furthermore, should you decide to enable SSH in the Administration page, the automatically generated anti-lockout rules will be updated to include SSH.



At this point the only cleaning up is the two preinstalled LAN rules, which will become defunct with this configuration and can be deleted.

My preference is to use the LAN interface for management and assign interfaces for the bridge members and describe them as INGRESS & EGRESS.