Messages

I think the option you want is at the bottom of the dhcp server configuration under "additional options".

Something like this:



The dhcpd version is "isc-dhcpd-4.4.1". The code it's built from is here: https://github.com/opnsense/ports/tree/master/net/isc-dhcp44-server

Let's check some settings:

* Your WAN interface should be set up and have an IP and a gateway
* Your VLAN interfaces should be set up and have an IP, but no gateways
* You should have a default gateway set up under "System: Gateways: Single" that can reach the internet (the WAN interface gateway)
* Under "Firewall: Settings: Advanced" "Network Address Translation" all options should be unchecked, "Disable all packet filtering. " should be unchecked
* Under "Firewall: NAT: Outbound" Manual outbound NAT rule generation should be selected and you should remove any rules
* Under "Firewall: Rules: (your VLAN interfaces)" you should add an allow rule matching everything*
* Under "Firewall: Rules: your WAN interface" you should add allow rules matching inbound traffic as required

(You possibly don't want to allow all traffic from your VLAN interfaces but I'm trying to keep things simple for now)

You could check "Disable all packet filtering" and then not have any firewall rules - if you really want a plain router with no filtering at all.

If you're still having trouble and don't see any settings matching that, can you try some tracerts?

This may be a stupid question, but have you made sure you don't have some sort of port security feature on your switch preventing your opnsense router from being able to work properly sending with various different source addresses? if that was the case that would prevent pfsense working too, but maybe you have setup a new test environment for opnsense so it seemed worth checking.

Code Select Expand

  plugins_configure('dns', $verbose);

https://github.com/opnsense/core/blob/c6034f651cd27a377e475f850e098e764a37e6a4/src/etc/inc/interfaces.inc#L2529

This doesn't pass in the interface.

Code Select Expand

    if (!unbound_interface($interface)) {
        return;
    }

https://github.com/opnsense/core/blob/master/src/etc/inc/plugins.inc.d/unbound.inc#L423

This checks if the interface which changed is relevant to unbound - but $interface is always an empty string as above.

Unfortunately from the unbound docs it looks like unbound really does need to be restarted when an interface it's specifically bound to changes, a HUP isn't sufficient.

If unbound's set to use all interfaces in both listen/outbound it should be ok as it binds to :: or 0.0.0.0, but the check for whether the interface is relevant isn't working.

edit: Thanks for helping/trying marjohn, I saw your suggestion earlier with the HUP if it's still running - shame it didn't quite work out

It happened again.

It's a shame that adding more WANs can actually make your connection less reliable with the current implementation.

I would like to try to fix this. You mentioned that changing IP should not cause unbound to restart, but it currently does, and I have mentioned the code responsible above.

It's probably not as simple as just removing the plugin_configure(dns) - it must be needed sometimes or it would not be there.

Do you know what the intended behaviour was here? Would it be reasonable for me to change it to reload the config if unbound is already running instead of restarting it?

I am not sure what was happening exactly.

Here's the system info and DHCP logs: https://gist.github.com/nallar/1102e6760820cb9963312803090f32bc

rc.linkup runs interface_configure with $reload = true, interface_configure then runs `plugins_configure('dns', $verbose);`.

the unbound plugin's unbound_configure_do then restarts unbound.

If a WAN connection is flapping, services restart repeatedly. This means that even if that connection is at a low tier in gateway groups and not in use it has an impact on services.

Unbound isn't very speedy to restart either, so the negative impact is high. It can be effectively down when a connection is flapping every 20 seconds.

Can we avoid restarting unbound in this case? (Is a reload sufficient?)

edit: Modified title as this seems to be an unbound specific issue

Does "Match priority" under "Advanced Options" for a rule do what you want?

No rush, if you can let us know in a week or two. :)


Thanks,
Franco

Still seems to be working :)

Applied the patch and changed IPv6 address back to none.

No reconnect loop yet, but it didn't always happen before so can't confirm that it is fixed.

I had a reconnect loop issue a while back where the modem interface would go up and down repeatedly.

I think there's a bug in rc.linkup after this commit:

https://github.com/opnsense/core/commit/fdc754e4261d333878549d1f43c980ae23a5f9ed

A static IPv4 address with V6 not configured will call interface_configure. Previously the empty($ip6addr) check would consider that to be a static address so it would not call  interface_configure.

My modem interface has only a V4 static address. Giving it a static V6 address resolved the problem.

You'll need to turn off sticky connections in the firewall advanced settings to get the behaviour you want.

What about fq_pie?

Seems to be working but not available in the UI. (Needs added here https://github.com/opnsense/core/blob/1667f2c3979afba5f137c960a95d900439baea48/src/opnsense/mvc/app/models/OPNsense/TrafficShaper/TrafficShaper.xml#L59 ?)

Not well tested as I use multi-WAN so can't check upstream works.

You could try running `unbound-checkconf /var/unbound/unbound.conf` in a shell.

Try with server:

Code Select Expand

server:
    root-hints: /var/unbound/root.hints

unbound allows duplicate blocks, so this should work, hopefully.

Code Select Expand

server:
  do-not-query-localhost: no

forward-zone:
  name: *
  forward-addr: 10.1.5.23@5353