Messages

It would be attractive for me also, especially where you could select the leases as @numachx suggests.

That sounds promising, Lantern5, assuming you are willing to do without / wait on a fix for ZenArmor.

While you had not mentioned you were running ZenArmor, I should still either have asked about other parts of the configuration or simply advised switching off all add-ons. As a comment, your additional tests changed the machine but not the NIC which was the more likely culprit, if ZenArmor were not intruding.

Thank you Lantern5. One test would be to try Opnsense on different hardware or at least with a different NIC, if you are able to. While I am also curious to know what DHCP you are running, it seems unlikely to be the problem given cycling the interface works. My conjecture is that the NIC itself is entering an unresponsive state when disconnected physically (LAN cable) or virtually (Opnsense restart) until it is itself re-initialised by one of the two means you mentioned. In that state its internal (to Opnsense) interface is up but its external (to LAN) is not -- it cannot even be pinged quite apart from not issuing addresses. That does not sound to me like an Opnsense problem.

[or issue the ifconfig em0 down | up command]

Since the Sophos + ER-X combo does not exhibit the same issues as Sophos + OPNSense; I came to the conclusion that the issue is not on the Sophos Box.

I did not imply I thought it was the Sophos box. The switch was from Lenovo M900 with its LAN ports to Ubiquiti ER-X, was it not? If not, what exactly are you swapping please? A labelled network diagram may be helpful

The em0 interface is up when I check via console, but does not respond to ping unless I power off the box and power it back up; or issue the ifconfig em0 down | up command

I need to completely power down the OPNSense box after a reboot, or a LAN cable change; before the OPNSense box starts passing traffic on the LAN interface. The interface is up, but does not do anything.

[my emphases]

The bold parts of the statements are in conflict. What statement is both true and complete please?

I believe this is definitely an issue with OPNSense.

Why, when you have also changed the hardware?

Your problem appears to be that after a reboot of the Opnsense box you need to reboot it, or the LAN interface, a second time before it will respond on em0. Is that correct? I ask because your description is a little ambiguous.

The behaviour of em0 contrasts with igb0 which continues to operate normally.

Realtek aside, I know of no other cases of similar behaviour under Opnsense, certainly not on several different boxes which I have used. Your own case shows that Opnsense has no difficulty on igb0.

I would be looking at the NIC. Perhaps a workaround could be to add a script that issues ifconfig commands to cycle em0 after startup completes. I have not thought about how to do that.

Yes, you could reset those devices to default.

That is my opinion, whereas Monviech's reply was a factual and reasonable response by an expert to an insufficiently-defined request. I realise that sounds a "tone-police" style of advice by me, please take it as kindly.

Though this is the case with all of what Opnsense offers, just look at the complexity of firewalling and NAT. Some meticulously craft their rulesets, others will go for any any any

which is an important reminder thanks.

I can understand the interest when new features like the Unbound/DNSmasq integration are released. My own network is simple in some ways, being home user(s) only, yet with different services (some public) separated vertically and horizontally with a strong emphasis on security with minimised damage from possible failure. Consequently I need to know clearly where new features fit, what are the alternatives, so I can maintain a clean and useable system. I shall keep happily batting along with Kea while looking for improvements as we always do.

I think that is the oddity, Monviech. The manual suggests only large or HA or complex installations might need Kea yet for basic DHCP with some reservations it is simple to implement and just works. That hardly defines as large or complex. People can use what they please though looking at MildDisaster's description of their progress, might they have had an easier time with Kea? That is not clear to me.

OK, thanks, no special reasons after the need to move away from ISC. My choice for my small installation was Kea. It has been flawless so I remain curious about other experiences.

I do not run DNSmasq. To help me understand the change, which reasons stated in the manual were persuasive for your particular case please?

I switched from ISC to Kea. Unbound listens on all ports and I have a redirection rule for DNS. Kea is not involved.

The fan is fine, although probably not needed if your router sits in plain air, not enclosed at all. They are designed to maintain a safe temperature in normal ambients and higher. You can see an approximation of CPU temperatures in the dashboard (but do not go down the CPU temp rabbit hole).

Given the powerful equipment and modest needs you have, I would have differed from earlier advice by saying definitely choose either of 2 or 3 (separate LANs in the latter case, you have ports not to need vLANs as such), skipping the extra equipment, cables, plugs. You appear to have no noticeable communication between computers, just internet links and at a relatively low speed. A much lesser bit of hardware would do the job without adding a switch. You are well future-proofed.

Everything runs fine with unbound and KEA.

Sounds like it is not broken, so what are you trying to fix or to improve?

In summary, the following question for @Franco:

1. Will ISC DHCP continue to be usable (via optional plugins) despite its EOL status?
2. Will KEA DHCP be usable for regular users even without HA?
3. DNSmasq is already active by default after a fresh installation of OPNsense. Will it be improved (and simplified) in the future?

While I believe the answers to 1 and 2 are yes and yes, I will wait for Franco to confirm.

Regarding the third, I have a supplementary question. Will the documentation contain concise instructions for turning DNSmasq off in a new installation, eradicating its presence, so new installations are more easily switched to Kea? I did not see that there during a quick look.

... or 192.168.88.0/24

In fact you could do worse than going straight to 10.x.x.0.24 where you generate the second and third octets randomly (once!).

meyergru's advice deserves further emphasis. A written IP plan will not only save trouble as described, it will also help you see what you really have when you come back to change your network months later. It will make fitting in new parts or systems much easier.