Messages

I have not seen ONE installer that cares about disk partition alignment, and they all tend to default to 8 byte alignment.

This part is complicated, and probably the huge reason I avoid installing from ISO unless a lot has changed across releases.

In a VM environment:

Install normally like I described above.

- Prepare a normal OPNsense installation as I described above, installed in a VM, to a VDisk of 14GB
- Confirm in /etc/fstab, that the only mountpoint is correctly using the GPT label, instead of block device:
  NO:  /dev/vt...p1 OR /dev/ada0p1 ... ...
  YES: /dev/gpt/efiboot0    /boot/efi msdosfs    rw    2    2
- prepare another Vdisk, partition with gdisk. I usually use a Linux-based distro, the utilities on them tend to not get in my way when partitioning.
- Start the first partition, EFI type, at 1MB into the disk, with size 255MB.
- Create a 2nd partition, FreeBSD-pZFS type (a504 on gdisk), size of about 15GB.
  - @nero355 It will start Aligned at 256MB.
- Still in Gdisk, Copy the names of the original partitions, efiboot0 and zfs0, respectively.
- I don't think FreeBSD cares about the File system labels as much as a Linux-based distro might.
- Format the EFI partition, mount both original and new EFI partitions, copy the contents of the original, over to the new one.
  - I even add a separate installation of Memtest86+ with grub, attached with various menu options and serial output for headless firewalls.
- dd the original ZFS partition, over to the new one.
- Disconnect both Vdisks, and start the VM with the Newly created Vdisk.
- Use zpool -e zOPN /dev/vtblk0p2 to expand the ZFS pool to use the remaining space above the original 14GB.

Customize your VM Firewall as much as you need, to avoid repeat work for multiple deployments

compress the image, and now you have an aligned image, ready for deployment of course in the config, replace references to vtblkX to ataX/nvmeX, and vtnetX... to igbX etc, that way the newly deployed hardware starts up with the correct interfaces ready to go. You can use the same EFI partition to store some configs from a more familiar OS to you, log into the console, copy the config.xml to /conf and reboot immediately.

If you booted into the USB through the CSM, it would make sense the installer would format the system meant to start the same way. The UEFI boot method has worked fine for me these past several releases.

I tend to shut off the CSM completely, disable secure boot and format the USB for strictly booting in UEFI mode.

In the installer, I think I chose the option ZFS UEFI Mode, no hybrid. It may be an advanced option. I also opt out of creating a swap partition. I haven't installed from ISO in a while since I setup the system in a VM and upgrade it there. Afterward, I use DD to put the the working system to a new disk and resize.

Aside from the monitoring tools, there is the scheduler, which can be instructed to run SMART short and long tests, on maybe weekly and monthly intervals, respectively.

In the event of drive failure. I have the most recent backup of the config.

On external disks, I carry a bootable Linux distro, and use it to deploy images to servers and firewalls. In the case of Opnsense, I have images created from pre-configured VMs, meant to cover 80% of most needs for a new site.

I use dd to the block device. after it's done, I resize the main partition, mount the EFI partition, drop the backup config in a directory.

Reboot to the deployed system, run:
zpool online -e nameOfPool /dev/adaXXX
to instruct ZFS to fill the remainder of the disk.

Make a copy of the config and do a search and replace of the interface device names from the virtualized to the real cards, like vtnet0 to igb0 for example. Copy the config over to /conf/config.xml, and immediately reboot, or with init 6 or your preferred method.

It's the quickest way to cover most disasters, of course the are more tools like HA (High Availability) to get a few firewalls running , with one of those acting as a spare to the other.

It doesn't hurt to have spare units with at least 4 ethernet ports, and spare SSDs on hand. I don't bother deploying images onto them until it's necessary.

The dd tool is fast enough, and the steps above can get you a working firewall within the hour.

It's easier to clone systems with a config and images kept up to date, it makes the hardware more easily replaceable when it fails.

cheers

Hi , yes great question, the Roku devices try to connect to IPs belonging to Oracle ASNs for telemetry services. The bonus is by blocking these, it also blocks telemetry attempted to be sent by an app or two on my and/or partner's phones.

I think these fields appeared more recently in recent production releases.

It should give more granularity. This could be useful, perhaps download one copy often, and distribute to client firewalls via an internal web server.

Classically, I update all aliases with a Cron Job on a weekly basis. It's only to make sure my URL sources do not ban me for getting too often.

If you want to shut down more of its telemetry, shut down access to Oracle related networks.

Do a lookup with a tool like
https://hackertarget.com/as-ip-lookup/

search for oracle

and load them into an alias, and make a  Floating rule using the alias as destination.

You'll see a little more getting blocked than you think. It breaks WebEx, but I don't trust Oracle at all.

This is just for the final screenshot

I noticed it is much more difficult to tell if a scheduled rule is active.

Perhaps in the new Rules system, when adding the column, it does not appear to pull in the icon asset corresponding to an Active/Enabled schedule on a rule.

It does still appear correctly on the classic rules system.

This happens in the current Business Edition OPNsense 26.4.1p2-amd64

as well as Community Edition OPNsense 26.1.11_10-amd64

Attached are screenshots, one of a Business Edition fully migrated to the new Rules system, and the last two are of the same Community Edition node, viewing classic rules in the New Rules system, and a view directly from the WAN interface rule in the classic view.

One observation with these mini-pcs,
is that running a system in a system on these older Protectli devices, like Proxmox,
feels like it would be TOO heavy for them.
It could add unnecessary lag too which is not preferable for a firewall.

For the price one of these FW series devices run for, you can get a few in stock, or run in a HA redundant configuration or something.
FreeBSD/OpnSense runs great as the bare-metal OS.

That being said, I think depending on how you configured your VM OS,
are you passing through the physical adapter, which may be ideal for a firewall.
Sometimes the VT Net virtualized network adapter struggles with real life events like
a cable physically disconnected from the medium.

Also is the virtual switch perhaps blocking VLAN tags through to the real switch.
For virtual application servers, I have often added a new network adapter,
that tags a VLAN externally, and the inner VM server has no idea.
You may need to allow VLAN pass through.

Here is some discussion on that
https://forum.proxmox.com/threads/vlan-passthrough.142272/

Hope that helps, but yeah unless you have a 1U server to handle VMs, I highly urge you to run OPN as the baremetal OS, make your life easier.

Hi

I didn't realize the text was that mangled, it is difficult to express many FW rules at once.
I replaced it with a screenshot attached to that post.
I added the missing local_link alias referenced in this guide
I also added the comprehensive list of Dangerous ports that I prevent accessing out on the internet.

Don't you have to set the FiOS router into bridge mode or similar in its web page?

That way the router just functions as a modem.

Here is an excerpt of my configurations, related to DNS and NTP redirection:

DNS and NTP redirection

Goals to solve with this solution:
- Provide local DNS services to clients.
- Redirect client attempts to circumvent local DNS, back to local DNS services
- Force clients to only use DNS UDP port 53 via their IPv4 address
- Block attempts to use port DNS over TLS port 853
- Block client access, to as great extent as possible, from accessing servers known to host DNS services via any protocol.

Pre-Requisites:

Firewall :: Categories (Optional step, including Categories used below)

Automatic: [ ] Unchecked

Name            # Color
0Frequent        0084ff
ASN              e7bc98
Danger          ff0000
Danger0          ff7f7f
Danger2          fa6400
Danger3          ffeb00
Danger4          ee00ee
Excep            808080
Firewall        ffffff
Host            84542a
Ingres          00ff00
Ingres0          80ff80
Ingres2          00bf00
Local            00ffff
Net              b37e52
Port            c990dd

Firewall :: Groups (Firewall Interface Groups)

Name        Members                          Description
    My Example:
LANs        <All Local except WANs>         
LANs        ex: OoB, LAN, GST, MGT, IoT, NVR  All Local networks, excluding virtual interfaces like OpenVPN, and WANs
    Policy Approach Example:
DNScli      LAN, GST, ...                    Interface networks you want to force local DNS

Firewall :: Aliases

Name:        danger_port
Type:        Port(s)
Categories:  Danger0, Port
Content:    853
Description: Block Dangerous Egress Ports
Notes:      This is part of a list of Ports I consider dangerous to access on the Internet.
Here is the full list of ports:
20:26,69,110,111,135:139,161:162,389,445,512:514,636,853,873,1001,1433,1521,2049,3306,3385:3393,5000             

Name:        excep_local_nets_net
Type:        Network(s)
Categories:  Excep, Local
Content:    !10.0.0.0/8,!172.16.0.0/12,!192.168.0.0/16,!127.0.0.0/8,!::1/128,!127.0.0.1/32,!fc00::/7
Description: Local Default Networks Exclusion
Notes:      This list of networks are used to clean up external Block Lists.
            It is possible to receive a list with local CIDR blocks,
            and be remotely hosed from your own local networks.

Name:        danger_symm_url_aRaw
Type:        URL (IPs)
Categories:  Danger2
Content:    https://raw.githubusercontent.com/crypt0rr/public-doh-servers/refs/heads/main/ipv4.list
            https://raw.githubusercontent.com/crypt0rr/public-doh-servers/refs/heads/main/ipv6.list
            https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/refs/heads/master/doh-ipv4.txt
            https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/refs/heads/master/doh-ipv6.txt
            https://raw.githubusercontent.com/oneoffdallas/dohservers/refs/heads/master/iplist.txt
            https://raw.githubusercontent.com/oneoffdallas/dohservers/refs/heads/master/ipv6list.txt
Description: Block Symmetric URLs raw
Notes:      This is part of a list of URLs to Block lists of IP addresses.
            These IP addresses must not be accessed, and should not be accessing you.
            If you want more ports, or have your own, let's share

Name:        danger_symm_url_aGrp
Type:        Network group
Categories:  Danger2
Content:    excep_local_nets_net,danger_symm_url_aRaw
Description: Block Symmetric URL Group
Notes:      Fuses the two above lists to sanitize the input of the external block lists.
            The WANs rules to use this alias, are not discussed in this tutorial.

Name:        fw_port_svc_rdr
Type:        Port(s)
Categories:  Firewall, Port
Content:     53,123
Description: Firewall Redirect Egress Ports DNS NTP
Notes:       Confines a client from accessing a DNS or NTP server,
             A NAT rule will loop a request back to the Firewall or whatever destination you choose.

Name:        local_link
Type:        Network(s)
Categories:  Local, Net
Content:     fe80::/10,169.254.0.0/16,ff02::/16
Description: Link Local Networks


Firewall :: NAT :: Destination NAT

Description: Fwd DNS NTP to FW
Interface:  LANs, OpenVPN (Or other Interfaces, or Firewall Interface Groups you created)
Version:    IPv4          (Do NOT specify IPv6, that way it is easier to know who accesses services)
Protocol:    TCP/UDP
Source ::
  Invert Source: 

  Source Address: This Firewall
  Source Port:    any
Destination ::
  Invert Source: 

  Source Address: This Firewall
  Source Port:    [ fw_port_svc_rdr      v ]
  Pool Options:  Default
Options ::
  No RDR (NOT):  [ ]
  Log:            [ ]
  No XLMRPC Sync: [ ]
  NAT Reflection: [ Disable  v ]
  Set Tag:        [            ]
  Match Tag:      [            ]
  Firewall rule:  [ Manual    v ]

Description: Fwd NTP6 to FW
Interface:  LANs, OpenVPN (Or other Interfaces, or Firewall Interface Groups you created)
Version:    IPv6          (Do NOT specify IPv4, that is handled above)
Protocol:    TCP/UDP
Source ::
  Invert Source: 

  Source Address: This Firewall
  Source Port:    any
Destination ::
  Invert Source: 

  Source Address: This Firewall
  Source Port:    [ Single port or range  v ]
                  [ 123                    ]
  Pool Options:  Default
Options ::
  No RDR (NOT):  [ ]
  Log:            [ ]
  No XLMRPC Sync: [ ]
  NAT Reflection: [ Disable  v ]
  Set Tag:        [            ]
  Match Tag:      [            ]
  Firewall rule:  [ Manual    v ]


:::::: So far, this will cover redirecting services 53 and 123, now we block circumvention ::::::

Firewall :: Rules [New] or classic, same concept

Please see attached screenshot

Please set a CRON rule to refresh your Aliases and DNS block lists.

Please feel free to ask questions
It is probably not fool-proof 100%,
I'm always open to improvement

Sources:
- This tutorial thread https://forum.opnsense.org/index.php?topic=9245.0
- https://github.com/dibdot/DoH-IP-blocklists
- https://github.com/oneoffdallas/dohservers/tree/master
- https://github.com/crypt0rr/public-doh-servers/tree/main

I have it in an alias full of ports clients have no business accessing.

Mind sharing? Looking to expand :-)

Of course I would be happy to, one moment, I'll take some screenshots and get my notes. To fully (to a great extent) Isolating DNS of any form to clients takes some firewall block and NAT rules, and aliases to lock the external DNS world to everyone except the firewall

I can confirm on my template firewall instances, both BE and CE,
which I use to deploy for production environments for a new sub key or a CE user.

I ran through a few tests in the hopes this helps development.

OPNsense BE 26.4_6-amd64:
No issues editing a user with a heavily modified Dashboard
No issues adding a new user with a password.
No issues editing previous user, and new user passwords.

OPNsense CE 26.1.6-amd64:
No issues editing a user with a heavily modified Dashboard.
No issues adding a new user with a password.
No issues editing previous user, and new user passwords.

OPNsense CE 26.1.7_1-amd64 :::::::::::
Cannot edit user with a heavily modified Dashboard.
No issues adding a new user with similar privileges.
No issues editing the new user with no prior Dashboard..
After resetting the Dashboard of the trouble user, the user can be edited.

Workarounds to edit the original user:
Reset the dashboard of the trouble user, and proceed to edit the user.
Edit a fresh config and insert a new password created from the passwd utility.

The problem returns immediately:
When heavily modifying the dashboard, the problem returns.
The problem desists if the dashboard is left in a default reset state.

I miss when I could import just the dashboard config, and transplant just it across multiple sites.
I noticed that option disappeared in the Backup/Restore when we moved to the improved interface.

Also please keep the Track Interface v6 / ISC DHCP v4/v6 available as long as possible or
until the feature is reproduced in whatever is the 'improved' way to do it.
From a GUI perspective it shouldn't matter what the underlying OSS Technology is,
it doesn't look good if there are like 2 or 3 competing services, and the newer ones remove features
we build infrastructure with.

It works perfectly, especially with our local few internet providers.

I am better at IT than I am sales. It is really hard to sell an underappreciated intangible like this,
especially when I encourage my clients to purchase a 3-year subscription.
Like an insurance agent sells insurance, you never appreciate it until you need it.
Life gets harder with a rug moving under us.
If I need DHCP, I just need to find DHCP services, configure my scopes, leases, prefixes etc.
I shouldn't need to worry if it's ISC, DNSMasq, Kea, CoreDHCP, Dibbler, udhcpd, wide, etc.

I think CISCO only gives you one service and handles its own underlying service.
But don't think like Cisco, think better than them.

Thank you have a great week.

Love, A3

I just block outgoing access to port 853. I have it in an alias full of ports clients have no business accessing.
The alias is used in a Floating rule to block local nets from accessing ports to !local nets