Messages

A-ha! Thanks.

That seems like it's not as obvious as it could be... maybe some explanatory text to "select a host above to add or edit aliases", or disabling the section (dimming it) until a host is selected.

Thanks again!

[are]

Today I scheduled a maintenance window to upgrade from 22.1.4_1 → 22.1.10_4 → 22.7 → 22.7.2.

Everything seemed to go smoothly (it just finished a few minutes ago, so still checking things) but one thing I noticed is that all of my host aliases in Unbound are gone!

They are still in /conf/config.xml (for now!) but I'm afraid applying any changes to Unbound will nuke them, since they don't appear in the UI. For reference, the host and domain overrides previously defined in Unbound do show up as expected, but the "Aliases" table on the "Overrides" page is empty.

I went looking at this right away because I was really hoping 22.7 might have CNAME support for Unbound's local-data in host_entries.conf, but no joy...

Any ideas on the missing aliases?

Thanks for the link! I was looking for someplace to put customizations in the UI.

FWIW, when it comes to adblocking, AdGuard uses this rule by default:

Respond with zero IP address (0.0.0.0 for A; :: for AAAA) when blocked by Adblock-style rule; respond with the IP address specified in the rule when blocked by /etc/hosts-style rule

(Using NXDOMAIN can cause some browsers / devices to fallback to alternative/secondary resolvers.) An NXDOMAIN response is required for the specific canary domains I mentioned (similar to returning NXDOMAIN for use-application-dns.net to prevent Firefox from using DoH by default).

Perhaps I missed it, but I can't find a way to add the equivalent of these config lines to Unbound in OPNsense.

server:
    local-zone: "mask.apple-dns.net." always_nxdomain
    local-zone: "mask-t.apple-dns.net." always_nxdomain

When these domains are not resolvable, iOS alerts the user that iCloud Private Relay is not available on the network, and gives the option to disable it or to use a different network (see "Allow for network traffic audits" in this document for more information.)

Is there some place to add custom unbound.conf stanzas?

Thanks for the reply.

I'll go ahead and implement that approach.

[scutil --dns]

A little background:

I use AdGuard Home as the primary resolver in my OPNsense-based network, and then have AGH pointed at OPNsense (running Unbound) to resolve (static) DHCP names. (AGH runs in a container and does not have any IPv6 connectivity.)

Recently I noticed that macOS was sometimes bypassing AdGuard.

Looking at the output of scutil --dns on several Macs on the network, I noticed that macOS was including the EUI-64 IPv6 address of the OPNsense LAN interface as a name server, along with the IPv4 address defined in the DHCPv4 config.

radvdump shows that there is no RDNSS or DNSSL being advertised.

I couldn't figure out where this was coming from!

I did some experimenting, and added this patch to /usr/local/etc/inc/plugins.inc.d/unbound.inc:

192a193,196
>             if ($tmpadr != "::1" && $tmpaddr != "fe80::1%lo0" && strpos($tmpaddr, ":")) {
>                 continue;
>             }
>

(The patch prevents Unbound from binding to any non-loopback IPv6 addresses.)

Lo and behold, it solved the problem! macOS no longer includes the EUI-64 address of the LAN interface as a DNS resolver. It would appear that macOS is "automagically" determining if the default gateway can answer DNS queries, and if it can, it adds it to the system configuration.

This behavior occurs whether radvd is configured as "Managed" or "Unmanaged".

Is there a supported way to prevent Unbound from binding to IPv6 addresses? Does the "Network Interfaces" configuration section for Unbound need to be enhanced to separate out IPv4 and IPv6 variants of each interface so it would be possible to bind to only IPv4 addresses on an interface?

Thanks for any insight!

[2021 Apple TV 4K]

I'd like to block unwanted IPv6 Router Advertisements from certain devices on the LAN (specifically, Thread-capable Apple devices: the 2021 Apple TV 4K and HomePod Mini).

Because these devices have Thread radios, they act as WiFi-to-Thread bridges, via these IPv6 RAs.

Normally, these RAs wouldn't be an issue, and most people probably never notice them. For reference, I ran radvdump on the firewall, and this is what they look like:

Code Select Expand

interface igb2
{
AdvSendAdvert on;
AdvManagedFlag off;
AdvOtherConfigFlag off;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 0;
AdvDefaultLifetime 0;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvSourceLLAddress on;

        prefix fda5:29ff:3b2c:1::/64
{
AdvValidLifetime 857;
AdvPreferredLifetime 0;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition

        route fdb0:dd88:d3ec::/64
{
AdvRoutePreference medium;
AdvRouteLifetime 1800;
}; # End of route definition
}; # End of interface definition

HOWEVER, the RAs are very problematic for devices on the LAN that utilize the Cisco AnyConnect VPN client for secure remote access. (And for what it's worth, both MacOS and Windows system are affected by these RAs.)

Why? Any change to the network configuration (such as the addition or removal of an IPv6 address on an interface) is detected by AnyConnect, and to "secure" the system, it updates all its pf rules and then runs pfctl -F states to flush the state table, breaking all existing connections, which, of course, is unacceptable from a user perspective. And since these RAs have 1800s lifetimes, this can happen every 30 minutes!

Code Select Expand

vpnagentd: (libvpncommon.dylib) [com.cisco.anyconnect.vpn:acvpnagent] A network interface address has gone down.
vpnagentd: (libvpncommon.dylib) [com.cisco.anyconnect.vpn:acvpnagent] A routing table change notification has been received.  Starting automatic correction of the routing table.
vpnagentd: (libvpncommon.dylib) [com.cisco.anyconnect.vpn:acvpnagent] A new network interface address has been detected.
vpnagentd: (libvpncommon.dylib) [com.cisco.anyconnect.vpn:acvpnagent] Reconfigure reason code 15: New network interface.
vpnagentd: (libvpncommon.dylib) [com.cisco.anyconnect.vpn:acvpnagent] A routing table change notification has been received.  Starting automatic correction of the routing table.
vpnagentd: (libvpncommon.dylib) [com.cisco.anyconnect.vpn:acvpnagent] Automatic correction of the routing table has been successful.
vpnagentd: (libvpncommon.dylib) [com.cisco.anyconnect.vpn:acvpnagent] The entire VPN connection is being reconfigured.

Obviously I have an IPv6-capable network, and it is desirable to have devices on the LAN be able to access the HomePod Minis and Apple TVs, so I don't want to put them on a different VLAN. But since I don't have a need for Thread, I would like to block the RAs coming from these devices.

These are wireless devices, so the RAs come in via Ruckus APs which are connected to switches on OPNsense's LAN1 interface.

So my question: What's the best way in OPNsense to block IPv6 RAs from specific devices?

Prefix tracking in VIPs sounds great. 👍 Hope there's some workable logic that allows that to get implemented. 😍

Once I've assigned an "IP Alias" VIP (like fe80::2) to a LAN interface, how do you get that IP Alias address advertised as the IPv6 default route for IPv6 clients? 🤔

I had not considered using a Virtual IP like this. Are there any examples showing this configuration? (I have not had the need to use Virtual IPs in my configuration yet, so am unfamiliar with the implications to existing rules, for example.)

Is this only for link-local addresses (#1 in my post) or do a Virtual IPs also make it possible to specify the host portion of a delegated prefix for the firewall's tracked interface address (#2 in my post)? (Right now, the firewall always uses an EUI-64 address in the PD.)

Thanks for the continued insights!

[fe80::1%igb0]

A couple IPv6-related questions:

1) Is there any way to specify the link-local addresses and avoid the EUI-64 auto-generated addresses?

e.g. I'd prefer to see fe80::1%igb0 as my link-local instead of fe80::4242:42ff:fe42:4243%igb0

2) Similarly, when an interface's IPv6 Configuration Type is set to Track Interface, is there a way to have the tracked-interface always use the ::1 address (for example) of the delegated prefix instead of the prefix plus the lengthy EUI-64 address?

I'd prefer to use "sane" addresses for my gateways if possible.

Thanks for any suggestions!

I'm new to OPNsense, but noticed a couple days ago IPv6 addresses were not being given to devices on the LAN side. A restart of radvd got it working again.

Would a potential work-around for this issue be to set up a cron job to pkill and then restart radvd once a day?

[IPv6 Configuration Type]

A couple IPv6-related questions:

1) Is there any way to specify the link-local addresses and avoid the EUI-64 auto-generated addresses?

i.e. I'd prefer to see fe80::1%igb0 as my link-local instead of fe80::4242:42ff:fe42:4243%igb0

2) Similarly, when an interface's IPv6 Configuration Type is set to Track Interface, is there a way to have the tracked-interface always use the ::1 address (for example) of the delegated prefix instead of the prefix plus the lengthy EUI-64 address?

I find using "sane" addresses for the gateways makes dealing with IPv6 a little easier...

Thanks for any suggestions.

Ah, thanks!

This approach does seem easier.  ;)

The only other thing I had to do was run:

opnsense-update -t opnsense-devel

before I could run make upgrade.

Thanks again!

My end-goal is to add a bit of new functionality and open a Pull Request. I believe all of my changes are restricted to the core repo.

I thought about "working on a live system", but figured it might be good to follow the "setting up a build system" steps, but as you can see, I didn't get very far.

Is "making a dvd" and then installing from that the only other way?

Apologies in advance for this newb first post but I feel a bit lost in this FreeBSD world...

I've successfully installed a FreeBSD-12.1 VM and followed the Setting up a build system steps. That all went fine.

Then I found a post in the forums that said to run something like:

make prefetch-packages,base,kernel VERSION=20.7.1

which also seemed to work.

Next I ran:

cd /usr/core
git checkout -b my-new-branch

and made a simple change (just as a test), added and committed it, but now I don't know what's next.

I saw something about needing to set COREBRANCH=my-new-branch?

So my questions:

• How do I rebuild core so it picks up my change(s) (ideally without having to rebuild anything else)?
• Once there's a new core, how do I go about testing the changes? Do I need to keep re-installing OPNsense from an image, or is there a more efficient way? (The files I'm changing are just .php and .inc files, in case that makes things easier?)

Thanks for any help.