Messages

Yes, thank you, all clear now. The ISC part will be removed from the docs, see this PR, already merged: https://github.com/opnsense/docs/pull/744

[opnsenseyay.org]

I haven't found an answer to my (edge-)case yet. I have a real domain on my IPv4/IPv6 address, resolvable from outside, let's say opnsenseyay.org. This points to port 80/443 points to a server in my network via firewall rules. I want my internal clients, if they ask for something.opnsenseyay.org to get a response from Dnsmasq only (via forwarding rule Unbound per the docs). If I do this, it resolves but it takes a long time. I found out that Unbound tries both: so it queries for outside (via 1.1.1.1 in my case) AND forwards to Dnsmasq. The queries from 1.1.1.1 return NXDOMAIN (because it doesn't exist) and from Dnsmasq there is a valid response via DHCP mappings. Both are technically not wrong. How to avoid Unbound from ever asking 1.1.1.1 for this domain "opnsenseyay.org". Apparently "Query Forwarding" doesn't work as I expect. Probably my bad, but how do I solve this?

EDIT: I think maybe my issue is this https://github.com/opnsense/core/issues/8708 and should be resolved in the next release?

Is the setting "Register DHCP Static Mappings" in Unbound not longer needed if internal queries are forwarded to Dnsmasq and you don't use ISC DHCP? It is my understanding that this setting refers to static mappings in ISC DHCP (seems logical), but I did not find a definite answer and I can't test it because I haven't set this up yet. If so, maybe add this to the help-description of this setting in Unbound.

EDIT: In the docs it's stated as "Register ISC DHCP Static Mappings": https://docs.opnsense.org/manual/unbound.html
That answers my question, but it's not the same text as in the Unbound Settings.

EDIT2: See this commit: https://github.com/opnsense/core/commit/139a3add4bb4360e2dda8f3251283e0173b0f980
Will be deleted as it's for Kea too.

What if I want only stateful DHCPv6 without SLAAC, which corresponds to the "Managed" mode under Services > Router Advertisements?  None of the DNSmasq RA modes seem to do this.  Possible using DNSmasq?

RA Mode set to "Default" will be same as "Managed" mode I believe. ?

I ended up using Services-Router Advertisements in Assisted mode again because I couldn't make it to work in dnsmasq... I did not try to set it to default and I'm too lazy to try it now, now thay it's working like I want.

I think it's nice to put this in the docs: https://docs.opnsense.org/manual/dnsmasq.html

Thanks.

Thanks!

[instead of]

Check out the note we added here:

https://docs.opnsense.org/manual/dnsmasq.html#dhcp-settings

Thanks, I've read that: and I saw I can combine them. That's why I asked the question, because in the statement quoted in my first post it says:

[...]set slaac instead.

That confuses me, because I read that as: Use slaac instead of ra-stateless.
In my old setup I had "Assisted" as an option under Services-Router Advertisements. I want the same behavior.

[and]

I'm moving to dnsmasq from ISC DHCP4/6. I will use Router Advertisements offered by dnsmasq and disable the other one in Services (seems more logical to me). In the dnsmasq docs under dhcpv6 and router advertisements found here it is stated:

! Attention
With ra-stateless, clients will only generate a SLAAC address. If clients should additionally receive a DHCPv6 address, set slaac instead.

I wonder if this is correct (or maybe I do not understand this correctly).

I want clients to be able to use SLAAC and DHCPv6.

Per above statement I should set RA mode to slaac only (at least that's how I read this), while it seems to me that setting slaac and ra-stateless achieves this. Am I right, or is the statement right?

Same issue with me, even with default theme.
Running bare metal on a Protectli VP2420.

To add: Manually rebooting does only work the second time in 24.7.5
Crowdsec seems to be the issue here. Disabling it and rebooting works as normal.

Same. No reboot with crowdsec installed. Had to reboot manually.

[EDIT:]

I installed it, but I get the feeling that something is not right in the tutorial under the Firewall rules: https://www.zenarmor.com/docs/network-security-tutorials/how-to-install-and-configure-crowdsec-on-opnsense#adding-firewall-rules

Should the Direction not be "in" instead of the stated "out" here in the floating rules? It doesn't make sense to me. The rule as stated in the tutorial seems to do nothing, but it makes sense to flip it to "in": It is working when I test it then. You can simply test it by pinging one of the IP's in the blacklist.

EDIT: I see someone else has made this remark already. Read too fast. They should correct it. I will contact them.

Cannot confirm this regarding Unbound. No idea about chrony.

Code Select Expand

# sockstat -n | grep :53
59       unbound    75740 5   udp6   *:53                  *:*
59       unbound    75740 6   tcp6   *:53                  *:*
59       unbound    75740 7   udp4   *:53                  *:*
59       unbound    75740 8   tcp4   *:53                  *:*


I found that out too! And SSH'ing in the OPNsense box you van easily do

Code Select Expand

nslookup whatever.com ::1

And that works!

But in practice, doing an nslookup to an arbitrary IPv6 dns server (using the IPv6-address, not the hostname) from a node in my network fails with the ::1 rule in place, while the same succeeds for IPv4 (due to the 127.0.0.1 rule). It's almost if ::1 in this case does not redirect to OPNsense itself but to the machine asking? Weird.

Exact the same goes for Chrony and probably every service. ::1 does not work the way I think it works from a remote host in my network - not the same as 127.0.0.1, I suspect.

[not]

I wanted a PF rule so all DNS / NTP traffic on my network not going to my OPNsense would be redirected to localhost (the OPNsense box itself) in order to transparantly redirect this traffic. I have a dual stack (IPv4/IPv6) setup.

Easy enough for IPv4, for example DNS, but same for NTP (but different ports and only UDP).
I have allow rules for DNS / NTP under Firewall-Rules-WhateverInterface

NAT Port Forward:

• Interface: Interfaces I want
• TCP/IP: IPv4
• Protocol: TCP/UDP
• Destination / Invert: selected
• Destination: Alias of my OpnSense box
• Destination Port Range: DNS-DNS
• Redirect target IP: Single host or Network: 127.0.0.1
• Redirect target Port: DNS

Works perfectly for IPv4.

For IPv6 however, I would expect that the only things I have to change are:
The 2nd one: TCP/IP: IPv6
The 7th one: Redirect target IP: Single host or Network: ::1

I found out this is not working. Unbound and Chrony, which I use for DNS/NTP, apparently bind on 127.0.0.1, but not on the IPv6 counterpart ::1.


I already found a workaround after too many hours of research and trying:

• Under Interfaces-Virtual IP's make a virtual IPv6 ULA on the Loopback interface, for example fd08::1/128.
• Restart Unbound and Chrony (they now bind to fd08::1/128).

Make a NAT Port Forward rule:

• Interface: Interfaces I want
• TCP/IP: IPv6
• Protocol: TCP/UDP
• Destination / Invert: selected
• Destination: Alias of my OpnSense box
• Destination Port Range: DNS-DNS
• Redirect target IP: Single host or Network: fd08::1/128
• Redirect target Port: DNS

To make things easier you could also make an alias under Firewall-Aliases to fd08::1/128 or whatever ULA you choose.

All set and done. Posted this for the benefit of the earth but also: I can't handle that I don't understand why it doesn't work with ::1? Or did I accidentally found a bug (probably not)? Maybe someone here could explain that, so I can sleep and give my brain some rest.

Thanks and cheers!

The interfaces overview has been rewritten from scratch for 24.1 and for some reason the delegated prefix (and some other information like DNS servers) wasn't included.

https://forum.opnsense.org/index.php?topic=38223

Thanks, missed that. Posted it there (too).

Being able to see the delegated prefix seems pretty important. It would be really nice if it was added back somewhere in the UI. I'm not even sure what if any command I can run in the terminal to retrieve it as a workaround. Does anyone know?

Ran into this myself and posted about it. I think it should be (re)added. I now have to do a

Code Select Expand

ifctl -6pi [interface]

on the console to see it.