Messages

This may be related to an issue with upgraded setups and multi-WAN in general. https://github.com/opnsense/core/issues/9702
There may be a setting hiding in the config somewhere that's causing the issue; multi-WAN with a fresh install appears to work properly. Don't know if you want to start over and reconfigure everything.

You're probably going to need a reinstall. If there's no direct 26.1.3 image, an upgrade from the latest version available should hopefully not go the same way.

Stupid question, did you try re-running the update process?

Another suggestion to try, if you don't want to migrate from dnsmasq to kea - set a machine with a static ip and disable dnsmasq, then try to start unbound. If it succeeds you know something in dnsmasq is blocking it.

I'd suggest migrating your dhcp handling to kea and disabling dnsmasq entirely and seeing if that fixes your issue. Depends on how much work it'd take.

Grok's link expires after a while; Going to paste it here so it's preserved for future reference...

**To enable SSH on OPNsense when you've lost WebUI access, use the built-in console menu (available via physical VGA/keyboard, serial, or VM console).** This works because SSH configuration lives in `/conf/config.xml` (the central config file), and the console gives you shell access to edit it directly. No internet or WebUI is required.

### Step-by-Step Instructions

1. **Access the console** 
  - Connect a monitor + keyboard (VGA) or serial cable. 
  - In a VM (e.g., Proxmox/ESXi), open the VM console. 
  - Power on or reboot if needed. Log in as **root** with your root password (default is usually `opnsense` on fresh installs, or whatever you set).

2. **Enter the OPNsense menu** 
  You'll see a numbered list (something like): 
  ```
  1) Assign Interfaces
  2) Set interface(s) IP address
  ...
  8) Shell
  5) Reboot system
  ...
  ```
  **Choose `8) Shell`** (this drops you to a FreeBSD root shell).

3. **(Optional but recommended) Verify current state** 
  ```
  ssh localhost
  ``` 
  or 
  ```
  ps aux | grep sshd
  ``` 
  If nothing is listening on port 22, SSH is disabled.

4. **Edit the config to enable SSH** 
  ```
  vi /conf/config.xml
  ``` 
  (vi is built-in; press `i` to insert/edit, Esc to exit insert mode, then `:wq` to save & quit. If you prefer nano: `pkg install nano` first.)

  - Press `/` then type `system` and Enter to jump to the `<system>` section. 
  - Inside the `<system>` ... `</system>` block, **add or edit** the `<ssh>` subsection so it looks like this (place it near the end of the `<system>` block, before `</system>`):

    ```xml
    <ssh>
      <enabled>1</enabled>
      <port>22</port>
      <permitrootlogin>1</permitrootlogin>  <!-- allows root login (recommended for recovery) -->
      <passwordauth>1</passwordauth>        <!-- allows password login -->
      <!-- Optional: restrict to LAN only -->
      <!-- <interfaces>lan</interfaces> -->
    </ssh>
    ```

    - If a `<ssh>` block already exists, just change `<enabled>0</enabled>` (or missing) to `1` and add the other lines as needed. 
    - Values like `1` (or sometimes `enabled`) both work; `1` is standard.

5. **Apply the changes** (no reboot needed in most cases) 
  ```
  /usr/local/etc/rc.sshd restart
  ``` 
  or 
  ```
  configctl sshd restart
  ``` 
  (If neither works: `pkill sshd; /usr/local/sbin/sshd`)

  You can also just reboot from the menu (exit shell with `exit`, then choose `5) Reboot system`).

6. **Test SSH** 
  From another machine on the same LAN: 
  ```
  ssh root@YOUR-OPNSENSE-LAN-IP
  ``` 
  (e.g., `ssh root@192.168.1.1`). It should connect and drop you straight into the OPNsense menu.

### Extra Tips & Common Fixes
- **If you also lost WebUI access** (same root cause): 
  In the same `/conf/config.xml` edit, look for the `<webgui>` section and make sure it has `<enabled>1</enabled>` and no overly restrictive `<listenaddr>` or `<interfaces>`. 
  Or simpler: from the console menu, choose **2) Set interface(s) IP address** → it often offers to "restore web GUI defaults" (switches back to HTTPS on all interfaces).

- **Firewall rules**: 
  Once SSH is enabled in config, the built-in **anti-lockout rule** (on LAN) automatically allows port 22 to the firewall itself. You don't need to add a manual rule for LAN access.

- **Security notes** 
  - Only enable root login temporarily if needed. 
  - For production, create an admin user in the admins/wheel group, add your SSH key under **System > Access > Users**, then disable password/root login later (when WebUI is back). 
  - Restrict listen interfaces to LAN only in the `<ssh>` block if desired.

- **Backup first** (good practice): 
  Before editing: 
  ```
  cp /conf/config.xml /conf/config.xml.bak
  ```

This method is the standard recovery path documented across OPNsense forums, GitHub issues, and troubleshooting guides. Once SSH is up, you can fix the original WebUI issue from the shell or re-enable the GUI properly.

If you run into any error (e.g., XML syntax), paste the exact error here and I can help debug the config snippet. Good luck!

This is apparently an issue with upgrading to the new opnsense version. You can try changing the destination NAT entries to "register rule" and deleting any old rules you had regarding the forwarding. I tested this as working with a fresh install but still haven't gotten my old setup working properly. More info at https://github.com/opnsense/core/issues/9702

First off, turn off DHCP on it. Select it under the Interfaces menu and give it the IPv4/v6 settings it needs. Then under settings/gateways add it as a gateway.

Edit: I should mention you can rename it too.

Wifi was broken in general for the 26.1 release. I'm surprised it was working for you. Try the latest update. You may need ot delete and reinstall the wifi.

Note that a quick test using the "Register Rule" method on 26.1.2 was not successful; I'll dig further later...

I should also mention that my setup is rather complex and that would complicate picking out the issue. I could maybe set up a test rig but then there's still so much that needs to be passed around.

If you really need it, I can set up said test rig, but it would be best if we could communicate more directly.

You should be able to do a dual wan test just by plugging both interfaces into the same source network with dhcp, then watching packets out of both using tcpdump.

Looks like it's been flagged as support, or in other words, "the user is doing something wrong, it's not a bug". Don't expect a fix any time soon. :(

26.1 appears to have broken dual NAT. https://forum.opnsense.org/index.php?topic=50571.0

Note that I've worked around this issue by setting the WAN I want to run servers from as default gateway and adding rules to all LAN nets to forward traffic to the other gateway. This breaks my failover plan and won't help if you're serving via multiple WANs so it's not perfect.

Note that I've worked around this issue by setting the WAN I want to run servers from as default gateway and adding rules to all LAN nets to forward traffic to the other gateway. This breaks my failover plan and won't help if you're serving via multiple WANs so it's not perfect.