Messages

HAOS is a complete Home Assistant appliance, application, database, everything in one VM.

I know, I have one running here. It would actually be one of the easier entities to relocate, since it isn't very widely interconnected. My main smarthome controller is ioBroker, and that has it's threads everywhere. For me, that's the beauty of it: Having data from all sources in one place. Even HA is but a sensor to ioBroker in my setup.

That's why I said that "corporate may be less complex": In production setups it's easier to characterize a system as doing either this or that. It either has internet access or not. It either needs user interaction or not. If you need one more job done, you put up one more system to do it.

In home networks, everything needs everything else. That's a bad place for applying corporate concepts like a DMZ.

VLANs are a DMZ ... I am not getting your last sentence. As soon as you have two VLANs, one "trusted" and one with reduced access rights, you have a DMZ.

My idea of a DMZ is is the hierarchic "a place between", isolated by routers on either end, with each segment able to reach the one "above", but not "below" itself. So the internal net could reach the DMZ, and the DMZ could reach the public net, but the DMZ would never under any circumstances be able to reach the internal net.

My VLANs are designed more "side-by-side", in that each VLAN may or may not reach the public net, and there are explicit rules for when a device from one VLAN needs to reach a device from another VLAN for a specific service (only). But these rules may go in either "direction" as required for the job.

Functionally not that different, yes. I wouldn't have called my VLANs a DMZ, though. But surely that's semantics.

Place the MQTT broker and the Home Assistant (HAOS) VM in the IOT network.

How will HA then access e.g. the database server? The DB I want in my internal net, not potentially exposed in the DMZ.

I would have to move much of my infrastructure from internal to the DMZ. About the only parts left would be the PCs I work on.

Even my file servers would need to be split into a "secure" and "non-secure" part, the latter of which moved to the DMZ. But these servers are exactly what I need to protect most.

On the other hand, if everything is in the internal zone (no DMZ at all) I can sort the devices comfortably into VLANs. I feel I'm more flexible with firewall rules between VLANs than I could be with routes between internal/DMZ networks.

@150d, when you describe what needs to talk to what, think also about which device initiates a conversation.

Well, take a IoT device that has a web interface for administration, but passes their sensor data by MQTT. If you put that into a DMZ, you would need one route to access the web UI from the inside net (no problem), but also a route from the DMZ into the inside net to reach the MQTT broker.

There is not much point in having a DMZ in the first place if you poke holes into it for every other device.

These are excellent points. Big thanks, everyone.

I think @meyergru put it best: I'm NOT really thinking about a true DMZ after all, because I can't separate my devices properly. Currently I'm doing this with VLANs and firewall rules the best I can, because everything is awfully interconnected. For example, my "dirty" IoT devices also need to talk to the smarthome server, which needs to talk to my multimedia equipment, which needs to talk to a file server. That doesn't mean the IoT's need to talk to the file server, but I can't completely isolate the segments either. A home network may be more complicated than corporate in that way because the existing equipment will "have to do it all".

So the best I could do would be "router-behind-router", just as you said. But this wouldn't have much of a benefit securitywise, just be a more complicated setup.

I guess it comes down to a "gut feeling" thing: Connecting a raw modem directly to my main router, firewalled or not, just feels wrong. But the only additional protection I would get by pulling it out to a dedicated, second OPNsense would be configuration error, maybe(!): Even if I make a mistake in the firewall config of the main router, the second firewall on the dedicated "modem-runner" should still catch it. That is, provided the firewall rules are not just copied over (which I don't expect they will be.)


And thanks also @nero355 for your reminder about hardware choices (or lack thereof.) But that's covered, I will have a dedicated modem, either stand-alone or in SFP form factor. Most likely I will choose the stand-alone variant, since I read that SFP-modems can run a little hotter than I may be comfortable with.

Hi,

I can't make up my mind about how to design my home network:

Currently, I have a DSL router providing internet access through an integrated firewall, which routes into a DMZ, where OPNsense picks it up, firewalls it again and sorts the traffic into VLANs where my devices live. This gives me two firewalls: One inside the DSL router and one in OPNsense. The DMZ is not used for anything else (I have no servers placed there.)

Next will be changing my internet access from copper DSL to fiber. With that transition, the DSL router will be exchanged for a fiber modem. Now I could ...

a) connect the fiber modem directly to OPNsense, using the OPNsense firewall and directly route into my VLANs or

b) have a second, dedicated OPNsense box that takes the place of the DSL router, does nothing but "run" the fiber modem, provides the first firewall and routes into the DMZ as before. The other OPNsense would then tap into the DMZ and route into VLANs just as it does now.

I just can't decide what to do:

- Just having my OPNsense/main router handle the fiber modem would be the least hassle with configuration, best performance (no unnecessary hops) and best efficiency (no unnecessary devices consuming energy.) But it would only be "one stage" of firewall.

- Keeping the DMZ would be a more complicated setup, with two stage firewalls, at "first instinct" hightening security. But with it would come the drawbacks already mentioned and I'm not sure there even would be a gain in security: If one firewall can be bypassed by an attacker, why can't two? And if I route traffic inbound through the DMZ anyway, what does it matter if it has to pass two OPNsense or just the one? Additionally, the DMZ is not used for placing servers anyway, it's just a pass-through network that serves no other purpose than being a "buffer zone".

What do you think? Do you think a DMZ would actually improve security in this case, or am I just kidding myself?

Regards

Okay, now that's different:

When I run tcpdump on the console, the missing packets are there. They are not there if I run a capture job on the GUI for the same interface, with or without promiscuous mode.

Make sure to eliminate glitches caused by DNS lookups by running e.g.

Code Select Expand

tcpdump -n -i <interface>


Does it make a difference that I'm using the GUI capture instead of running tcpdump on the console myself?

E.g. this packet:

(from firewall/log/live)

__timestamp__   2025-08-29T13:17:29
action   [block]
anchorname   
datalen   354
dir   [in]
dst   10.1.1.5
dstport   67
ecn   
id   62914
interface   igc0_vlan5
interface_name   VLAN5_IoT
ipflags   DF
ipversion   4
label   block to unrestricted VLANs
length   374
offset   0
protoname   udp
protonum   17
reason   match
rid   ccafb7f40b2dd9edf15670b0fdcbd410
rulenr   109
src   10.5.1.109
srcport   68
subrulenr   
tos   0x0
ttl   64

10.1.1.5 is a DHCP server, the client (10.5.1.109) is sending a unicast packet to the server. It shouldn't do that, there is a DHCP relay running on OPNsense which should handle all DHCP broadcasts (and which is working fine.)

I wanted to look at the packet to get a clue as to why the client is behaving in this way.

Sorry:

No, I don't use IPS.

Version is 25.7.2.

Hi everyone,

my firewall blocks some packets that I'd like to inspect further. But when I use "packet capture" on the interface, I don't see these packets. Is this because the packet filter runs before the packet capture, so that packets that are not let in by the firewall rule don't even make it to the packet capture?

Is there a way around that (to capture even packets not allowed into the firewall by a rule on the interface in question?)

(I had already checked the "promiscuous" box on the capture job.)

Regards

Hello,

I'm in the process of migrating OPNsense to new hardware with different interface names and will need to make adjustments in the export XML accordingly. Question is, what should I change the interface names to, especially the VLAN names?

I could just renumber them vlan01, vlan02... with no regard to their actual tag, as is the current "automatic method". Or I could use my own scheme like e.g. "LAN_V17" for the VLAN tag 17 on the LAN interface.

What would you recommend? Would the custom scheme have any drawbacks?

This may be a futile battle: Your receiver seems to be optimized for (car) navigation. It may not even be capable to serve as a precise time source.

What you could try:

- Disable all PPS processing on the client. Even if the receiver should "emulate" this signal over USB, it won't be reliable.

- Limit message types on the receiver to only the NMEA types required for timing. This will "free up" bandwidth and maybe enable the receiver to report more often, giving a more plausible signal to the client.

- Increase comm speed from 4800 to something higher on the receiver. Same as before, this may enable the receiver to give more regular reports.

- Make sure the receiver has a good signal. If it looses the signal every now and then, the client will tend to view it as unreliable.

... but again, consider whether it's worth your time: You won't get precise timing out of this device anyway, you might be better off using internet time servers in the first place.

Mornin' All,

I noted that in Services/Router Advertisements you can only specify two IPv6 DNS server addresses. I would like to use more than that.

Is there a reason for this limitation, or is it just the UI?

Regards

Hi,

I'm using OPNsense as a VM on a Proxmox host. A single NIC is "passed through" to the VM as a PCI device. OPNsense then uses a number of VLANs on this connection and is routing between them.

This works great, but it also makes the VM "non-migrateable" because VMs using PCI devices directly can't be moved to another Proxmox host on-the-fly. The alternative would be to give up on the pass-through device and instead provide a Linux Bridge to the VM. This could easily be mirrored on a second host if the need should arise.

But that would be a totally new device to OPNsense and I expect that it would completly screw up its interface mapping. Is there a way to manage this (swap out A for B in some INI file) or would I need to do the whole setup from scratch?

Regards

The DNS server(s) may be set either system-wide or individually for each DHCP-enabled interface:

System/Settings/General allow to specify "system DNS", which OPNsense itself will use and which are passed on to DHCP-enabled interfaces by default

Services/DHCPv4/[Interface] allows to specify the DNS server(s) passed to this interface only. If nothing is defined here, the system DNS servers are used.

If both are blank, you can enable Unbound to resolve DNS names (Services/Unbound). In that case, you can additionally set a "Query Forwarding" for your local domain to point to the Windows DCs.

Regards