Messages

With two 26.7.1_1 test VMs that I set up on Proxmox 9.2.4, tailscale is working normally. However, on the Interfaces/Assignments page, the status icon for the tailscale interface is red.

You cannot view this attachment.

Yet, on the Interfaces/Overview page, the status icon for the tailscale interface is green.

You cannot view this attachment.

Again, tailscale seems to be working normally, so I think the issue is cosmetic.

You cannot view this attachment.

Will

Sorry. I posted in the wrong place. I will repost in the 26.7 Series forum with screenshots.

Will

[**Posted on wrong forum**]

**Posted on wrong forum**

With two 26.7.1_1 test VMs that I set up on Proxmox 9.2.4,  Tailscale is working normally. However, on the Interfaces/Assignments page, the status icon for the tailscale interface is red. Yet, on the Interfaces/Overview page, the status icon for the tailscale interface is green.

Again, tailscale seems to be working normally, so I think the issue is cosmetic.

Will

On the Hosts, DHCP ranges, DHCP options,  and DHCP tags tabs, the "Enable selected" and "Disable selected" buttons seem to have no effect. Since there are no corresponding <enable>1</enable> / <enable>0</enable> commands in the config.xml file, is this just a cosmetic issue?




Will

In my case, the source and destination are present after rule import in both the config.xml file and in the grid display. So, the data does not go missing. The problem is confined to the edit window, where the source and/or destination seem to randomly show up as "Nothing selected."

Will

Same here. On my active OPNsense setup (version 25.7.11_1), I can access the OPNsense web interface using the tailscale URL. However, on my test setup (version 25.7.11_2), I am unable to access the OPNsense web interface using the tailscale url. After restarting the WebGUI, access via the tailscale URL works.

Will

It may not be related to your issue, but I had a similar Unbound DNS problem (after an OPNsense reboot) with name resolution for internal devices. My issue went away after I started Zenarmor (it was stopped for some reason) and ran a pending Zenarmor update.

As I was sorting through a DHCP issue with my Unifi APs after an OPNsense reboot, I noticed that name resolution was failing for internal devices. I restarted  Unbound and verified that my desktop (dhcp client) had the correct DNS server specified, but I still could not ping any of my internal devices by name. Looking through my Services on the OPNsense Dashboard, I noticed that Zenarmor was not running. I started Zenarmor and ran the pending update. I don't know whether Zenarmor being in a 'not running' state had anything to do with the name resolution failure, but after the Zenarmor update completed, name resolution was working again.

Will

[Overrides Host Definition]

Currently running 25.7.6
 
Word of caution: Novice at work!
 
I use Unbound DNS Overrides/Aliases to forward requests to NGINX Proxy Manager for my internal services. I started to add a new alias to one of my hosts and realized that my previously defined aliases were no longer visible in the Web GUI. Although the aliases were no longer visible, they still worked. This really puzzled me. As a test, I created a new Test alias on a previously used host, and the new alias was visible in the Web GUI.
 
I downloaded and examined the config file and confirmed that all of the no longer visible aliases were still defined in the config file. I noticed that although the host reference in the stanza for the test alias definition matched the corresponding host uuid, all of the stanzas for the aliases that were not visible in the GUI referenced a different host (uuid) for which I could not find a matching host definition.
 
Overrides Host Definition
 
        <host uuid="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx">
          <enabled>1</enabled>
          <hostname>local</hostname>
          <domain>xyz.com</domain>
          <rr>A</rr>
          <mxprio/>
          <mx/>
          <ttl/>
          <server>10.10.10.108</server>
          <txtdata/>
          <description>local via nginx</description>
        </host>
 
Test Alias
 
        <alias uuid="12e3fd92-4ead-4876-bc39-d0e74c559985">
          <enabled>1</enabled>
          <host> xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx </host>   ç Matches uuid above
          <hostname>test</hostname>
          <domain>local.xyz.com</domain>
          <description>Test Override Alias</description>
        </alias>
 
Existing Alias
 
        <alias uuid="12e3fd92-4ead-4876-bc39-d0e74c559985">
          <enabled>1</enabled>
          <host>yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy</host>  ç Does not match uuid above
          <hostname>existing</hostname>
          <domain>local.xyz.com</domain>
          <description>Existing Alias</description>
        </alias>
 
Since the host uuid in the Test Alias stanza matched the host uuid for the referenced host (Alias is visible), I decided to change the uuid values in all of the Alias stanzas to match the uuid values in the referenced host definitions. 

After I replaced all the Existing host uuid values in each Alias stanza with the uuid values from the referenced Host definitions, I restored the Unbound DNS settings from the modified config file using System/Configuration/Backups.  After the Unbound DNS settings were restored, all of my Unbound DNS Overrides/Aliases became visible in the Web GUI again.
 
By the way, I do not know how long the aliases have not been visible in the Web GUI. I found the mismatch between the uuid values in the Alias stanzas and the uuid values in the referenced hosts in my backup files going back at least to early July
 
Will

Hi Stefan,

I am interested in testing the Q-Feeds plugin.

Thanks,

Will

Hi, If you are using NAT with IPv6, make sure that IPV6 link-local addresses are not included in the list of source addresses for NAT66.

Background – My setup is dual WAN (Uverse fiber and Spectrum), with load balancing and failover, and I use NAT66 (I know the reasons that I shouldn't). About a month ago, I noticed that my WAN2 (Spectrum) interface did not have a global IPv6 address (dhcpv6 client). I checked the logs and saw the "dhcp6c transmit failed: Permission denied" error, but did not know how to interpret it.
 
Over a couple of weeks, I tried everything that I could think of to resolve the issue, but nothing worked. Then, I stumbled across a post about dhcpv6 issues, in which someone suggested that the problem may be related to NAT66. I looked at my NAT66 configuration and realized that included in the source alias list "Internal_All_IPv6" that I use for NAT66 was fe80::/10 (link-local addresses). I suspected that this might be interfering with DHCPv6 (Solicit, Advertise, Request, Reply) sequence, so I removed the link-local addresses from the NAT66 source alias. As soon as I did this, the WAN2 interface obtained a global address, and I have not had the problem since.

...just a newbie's suggestion of something to try.

Will