Messages

By doing it like so:

1. Unbound is your main DNS resolver. It either resolves internet DNS by itself, working as a resolving DNS or you configure it to use an upstream server, like 8.8.8.8 via normal DNS or DNS-over-TLS. You also tell it to "Do not forward private reverse lookups". The import part is that you instruct it to forward specific domains, namely, you private domains, to 127.0.0.1:53053. This includes the reverse domains, say "168.192.in-addr.arpa".

2. You configure DNSmasq to run on port 53053 and set it up to resolve your internal domains, it will use the system name servers as upstream servers. These do not even have to use 127.0.0.1 (Unbound).

Thus, regular queries go to Unbound first and are either forwarded to DNSmasq (if they match fordwarded domains) or resolved by Unbound.
Because the forwarded, local domains can be resolved by DNSmasq, you will either get an IP or an NXDOMAIN. And since DNSmasq is only ever asked for internal domains (by Unbound only), its upstream server will never get used, even if it is Unbound by accident.

I don't think this is working like that currently, as evident by multiple reports about it. I think it is already resolved as https://github.com/opnsense/core/issues/8708 and related changes. I will try on next release.

I believe it's unbound because when running a nslookup on my windows machine to a host that is in unbound's overrides, it times out twice before finally succeeding, suggesting unbound is choking on...something because it's a local lookup to unbound.

I'm seeing the same thing. I think current documentation is incomplete in a way of setting up this unbound to dnsmasq forward. And in fact I don't even see how it suppose to work in practice. Symptoms are like @Unspec described, timeouts and generally instability, it sometimes works, other times does not. It queries unbound multiple times, also with host.lan.internal.lan.internal.

If you think about it, unless I'm missing something it is lucky it even manages to return anything sometimes, breaking recursion.

If dnsmasq dns is set on alternative port, it will forward queries back to unbound which is main dns server. Unbound then sees that this query should be forwarded (back) to dnsmasq, which ask unbound again... and we get infinite recursion. I hope I missed something in configuration, because as it stand now it hardly can work like that.

I'm still confused about this one. Can someone explain how should a infinite recursion of dns resolution between unbound and dnsmasq prevented?

I'm not going to run two DNS services just to be able to resolve internal host names. This whole deprecation of ISC has been a mess. ISC+Unbound is exceedingly simple and functional, Kea and dnsmasq are both half-baked.

I felt the same until I read through the updated docs. DNSmasq is primarily being introduced for dhcpd. Using it also for local name resolution (via an unbound forwarding) means no unbound restarts on updated leases. You retain a recursive resolver and still only have two daemons running in order to provide DNS/DHCP. If it all works as described in the docs, I will be more than happy to switch since I was fond of dnsmasq from previous experience.

In theory it looks ok, but unfortunately in practice it is not stable currently. As reported in the other thread.

Wouldn't it be possible to register local leases in unbound in some other way? Running two DNS servers just for this seems like a low-effort workaround for limitation that shouldn't exist.

I believe it's unbound because when running a nslookup on my windows machine to a host that is in unbound's overrides, it times out twice before finally succeeding, suggesting unbound is choking on...something because it's a local lookup to unbound.

I'm seeing the same thing. I think current documentation is incomplete in a way of setting up this unbound to dnsmasq forward. And in fact I don't even see how it suppose to work in practice. Symptoms are like @Unspec described, timeouts and generally instability, it sometimes works, other times does not. It queries unbound multiple times, also with host.lan.internal.lan.internal.

If you think about it, unless I'm missing something it is lucky it even manages to return anything sometimes, breaking recursion.

If dnsmasq dns is set on alternative port, it will forward queries back to unbound which is main dns server. Unbound then sees that this query should be forwarded (back) to dnsmasq, which ask unbound again... and we get infinite recursion. I hope I missed something in configuration, because as it stand now it hardly can work like that.

Any news about this? Do we want to fix this before 22.7?

Oh, I just lost whole finished post when trying to send it, because it log me out. I guess we go again, probably shorter version this time and less coherent...

Indeed I can work with snapshots. I didn't know it is such painless to move to dev version. So I moved to 22.7.a_413 (7fdc163bf).

Issue 1. from OP is fixed, enabling interface seems to work as expected.

But there are still issues. Sorry for being chaotic before I wasn't sure how it should work exactly.

Disabling gateway does not adjust routes correctly. To recap I have gif0 device assigned to WANv6 interface that is used as upstream gateway for IPv6.

I will be disabling WANv6 interface which also controls associated gateway.

Code Select Expand

netstat -6rWn | grep gif0$

1. Nominal case, after reboot (WANv6 interface enabled)

Code Select Expand

Destination                       Gateway                       Flags   Nhop#    Mtu    Netif
default                           <ipv6>                        UGS        13   1480     gif0
<ipv6>                            link#10                       UH         10   1480     gif0
fe80::%gif0/64                    link#10                       U          12   1480     gif0
2a. After disabling gateway only (no change to 1)

Code Select Expand

Destination                       Gateway                       Flags   Nhop#    Mtu    Netif
default                           <ipv6>                        UGS        13   1480     gif0
<ipv6>                            link#10                       UH         10   1480     gif0
fe80::%gif0/64                    link#10                       U          12   1480     gif0
2b. After disabling WANv6 interface

Code Select Expand

Destination                       Gateway                       Flags   Nhop#    Mtu    Netif
default                           <ipv6>                        UGS        13   1480     gif0
fe80::%gif0/64                    link#10                       U          12   1480     gif0
3. After reboot (WANv6 interface disabled or only gateway disabled)

Code Select Expand

Destination                       Gateway                       Flags   Nhop#    Mtu    Netif
<ipv6>                            link#10                       UH          9   1280     gif0
fe80::%gif0/64                    link#10                       U          11   1280     gif0
4. After enabling WANv6 interface

Code Select Expand

Destination                       Gateway                       Flags   Nhop#    Mtu    Netif
default                           <ipv6>                        UGS        11   1480     gif0
<ipv6>                            link#10                       UH          8   1480     gif0
fe80::%gif0/64                    link#10                       U          10   1480     gif0

As we can see it is not consistent. 1 and 4 is expected. In 2 and 3 case I would expect there are no routes. Traffic is still routed through this gateway while I would expect there is no default route for IPv6. After disabling WANv6 interface firewall rules for this interface does not apply to traffic that is still routed there, but this is side effect. Also note that after reboot in case 3 MTU is set to default 1280, again side effect, because if device is associated to interface while this interface is disabled I would expect no routes created.

I hope I didn't forget anything, let me know if more detailed info is needed.

Thanks,
Kacper

First we would ideally be able to confirm the fix works

Can I test it without much hassle? Can I do opnsense-patch on them? Not sure they would apply cleanly? You mentioned before that some other changes are required, so probably I need to wait for 22.7?

As per design devices like GIF are stand-alone. Assignments can be used but are not required. That also means disabling assigned interfaces won't disable devices like you imply.

Ok, back to this then. I would like to understand. You said that "assignments are not required" and "disabling assigned interfaces won't disable devices like you imply"... ok. But in fact I don't care about the device itself. It can be active or not.

Shouldn't disabling gateway or setting it as not upstream remove the default route for this gateway (and therefore not route through GIF)? I don't see how it related to GIF, but disabling assigned interface disables the gateway and at this point why the routes are still there? I don't see how this is by design? How one handle multiple GIF tunnels if associated gateways/interfaces doesn't affect routing? Do you see my point? If not, let me know, I can rephrase my questions.

Indeed. If I save from "Interfaces: Other Types: GIF" gateway is enabled, but shows as offline, monitoring is not working (monitor ip is correct), I also need to go to "System: Gateways: Single" and save there also and then it works.

So which version it is then?

Version: 22.1.8_1

That also means disabling assigned interfaces won't disable devices like you imply.

Ok, if it by design like that, you can discard point 1. But still 2. seems like a bug, no?

So, I cannot disable gif tunnel without removing it? I can block traffic in firewall on given interface, but was intuitive for me to just disable it.

Hi,

I have HE Tunnel Broker configured (gif tunnel). I noticed two problems.

1. Disabling interface (assigned to gif tunnel) doesn't have an effect, routes are still there and traffic is routed through this interface. (gateway is disabled and not shown, but still works)
2. Re-enabling interface doesn't work correctly. Gateway is still "disabled" and from GUI there is no way to enable it, it never goes up. I need to reboot to get to valid state.

I want the ability to enable/disable interface, because I don't want to use it all the time. But currently I cannot do that apparently.

Thanks,
Kacper

Hi,

All traffic is logged as

Code Select Expand

let out anything from firewall host itself after NAT.

It makes logs huge and after a while, when `/var` is full, I need to restart machine, because opnsense is basically hung at this point. 

It seems quite strange and inconvenient to have all traffic logged and since it is default rule I cannot disable logging for it. I workaround the issue of hanging with limiting logs to 3 days, but still it is a problem to unnecessary log everything without ability to disable the logs without hacks.

Is is really intended default behavior? Maybe it is the VLANs? What are you doing to mitigate this log spam?

Thanks,
Kacper

Related to ESXi and VMX driver. Tunables like

Code Select Expand

hw.vmx.txndesc
hw.vmx.rxndesc doesn't work anymore. Need to set it up per device

Code Select Expand

dev.vmx.0.iflib.override_nrxds
dev.vmx.0.iflib.override_ntxds

You can read here what values are expected for this override. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237166

This apply to all hw.vmx tunables that you might have had before.

I still have higher CPU usage and as a result reduces throughput, but didn't manage to find the culprit yet.

Thanks guys for suggestions, but it turns out my ISP on mobile is a culprit. Actually it was working perfectly some time ago, but with pfsense, I made a switch to opnsense and it stopped working, so I assumed this is the problem. But it turns out in the same time my mobile ISP changed something on their end. I didn't have time to diagnose it further, but basically looks like the traffic is filtered...