Messages

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