Topics

Per the help in DNSMASQ:


IP addresses of the host, e.g. 192.168.100.100 or fd00:abcd::1. Can be multiple IPv4 and IPv6 addresses for dual stack configurations. Setting multiple addresses will automatically assign the best match based on the subnet of the interface receiving the DHCP Discover.

Has anyone had success with this? It doesn't work for me. I have a laptop that goes between networks (via VLANs and differing switches). The DHCP address offered only works on one of the three interfaces; the others pull outside of the reserved address for that interface. I've also tried this for dual-stack IPv4 and IPv6 where there are two addresses--one IPv4 and one IPv6; the DUID is set appropriately.

Cheers!

Title covers it pretty much. By "not working" I mean it is not updating in Cloudflare. This worked perfectly pre 24.7.

I have all of the information set correctly. When I used DDCLIENT, the logs show nothing under debug.

When I used "native", the logs show:

   Account 00000000-0000-0000-0000-000000000000 [cloudflare - Cloudflare DDNS xxxxxxxx.COM] error receiving ZoneID [[{"code": 6003, "message": "Invalid request headers", "error_chain": [{"code": 6103, "message": "Invalid format for X-Auth-Key header"}]}]]

I rolled and reimplemented the API key with no success.

I received a notification today in Zenarmor that there was a new version of the engine. I upgraded. It seemed to work out okay--the status showed (and still shows) a green "Running" status for both the engine and database. Well, not so much.

A few hours later, I see that the reporting data stops to a period very close to when I udpated the engine. Stopping and restarting the engine doesn't have any impact. There is no option to restart the database, as I'm using a remote Elasticsearch database. There is no data showing. Period.

I recall this happened a bit of time ago when I was using the local database option as well. There was an upgrade, I installed the upgrade, and the data stopped. My only recourse at that time was to start with new databases. So much for any historical data.

Is this happening to anyone else? My hunch is that the process to "talk" to the database just stops, but that is conjecture. I wish there was a way to restart the database service--but no dice for a remote database connection. The remote database is health, showing green for all indicies. This is not a remote database problem. It feels like it's trying to use a previously established connection that is no longer valid.

This product seems so unfinished to me. Little nagging problems that appear. Example: After 1.16 was released, every IPv6 address tied to one device was showing up as another device. It's hard to imagine that some level of QA wouldn't have caught that. I had many back-and-forth discussions about policies with them about a month ago. It was fruitless. First they told me it was an IPv6 issue. (I was using MAC addresses to slot devices between different policies...I have no idea how they connected those dots.)

To their credit, their support team is responsive and friendly. But, their only recourse seems to be to ultimately reqeuest a remote desktop troubleshooting session. I've posted about another issue related to many reports not displaying data when using a remote database. It's easily reproducible. But they want a remote desktop session. This seems reasonable if they cannot reproduce the issue. (Not really--they should have sufficient logging and other tools to mitigate the need for remote desktop sessions.)

Anyway...my ultimate goal with this thread is to see if others are experiencing the reporting database just stopping at a point for no apparent reason. (Even though it claims it is running.)

I added a new VLAN today and went through the usual processes. (Add VLAN with assigned parent, add interface, enable interface and assign static IPv4 address, add DHCPv4 configuration, enable.) I could not get any device on my switch to come up if it was on a tagged port for that VLAN, despite numerous switch configuration changes. (I usually blame the switch--but not for any specific reason; the port configured was the same as other ports albeit with a different tag.) I also walked through the process again on OPNsense with no success.

Rebooting the switch didn't make a difference. What did make a difference was rebooting OPNsense. When it came back up, the device worked. I replicated that port across others on my switch and they worked fine after the OPNsense reboot as well. This seems odd to me.

To me, it's a defect. Despite some of the other silly things OPNsense does (why does every VLAN "device" have to start with VLAN0, as an example), this one really makes me scratch my head. Certainly a lesson learned. I do not recall this behavior in the past, however.

Is this known behavior, and if so, is it normal for this platform?

Cheers!
    Joel