Messages

The goal for 25.7 default installation we're moving to:

Unbound as DNS (same as before)
Dnsmasq as DHCPv4 (away from ISC and ignoring Kea)
ISC for DHCPv6 (same as before)
Router Advertisements "radvd" as RA (same as before)

As you can se we're changing one variable here for 25.7. DNS isn't a concern either. It's all DHCP/RA that is going to change further as ISC moves to plugins in 26.1.


Cheers,
Franco

I'm curious. Why ISC for DHCP6 versus either Kea or DNSMASQ--or just DNSMASQ if ignoring Kea?

Got it. Thank you!

When I read the issue on Github, it appeared that dual-stack should work. Alas, I do not see those results either. Separately (IPv4 on one host entry, IPv6 on a second host entry), the correct addresses are allocated. If I combine IPv4 and IPv6 in one host entry (with the appropriate MAC address and client identifier [DUID]), the IPv6 address is not used.

Given that I do not need DHCP options outside of what are already offered in Kea through the UI, and since host DNS registration isn't something I need, I'll just move to Kea for both v4 and v6. (I don't agree with the approach of sticking with v6 on ISC; I'd rather have one area--and I'll be removing ISC when able to do so in 26.1.)

** REMOVED by Author **

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!

I'll answer a couple of questions from above, and then give the solution I found.

As to which auth I was using, I tried both global and api. For API, I did indeed have the API token set as "Edit" as one of the options. Ultimately I was able to get this to work with the username field left empty (I hadn't yet seen the recommendation to use "token"), and the check IP method set to "Interface." (Before, I had my email name in the username field, and the check IP method set to my WAN interface.

This is using the ddclient method, not Native. I may tackle the Native at some point, but it's not in the cards today, and probably won't be unless I hear of a compelling reason to do so.

I do not recall anything in the release notes stating that there were changes to this functionality. The complete configuration was identical to earlier versions (meaning I didn't modify anything), and it worked without issue. In fact, I brought up the prior version and verified that it worked correctly. So, something changed somewhere in the latest version of OPNsense. If Cloudflare is selected as the service, it seems to me that it should completely ignore the username field if it is indeed superfluous. (Or better still, do not display the field if it's not appropriate to the service selected.)

As an aside, earlier I'd noted that the ddclient service failed to start after trying Caddy as suggested earlier in this thread. Rather than re-hash what I did there, it's above. Suffice to say, the only way I could overcome the service not starting was to reboot OPNsense. I can think of very few reasons that one should ever have to reboot a firewall; this does not fit into a use case where I think it's justified. Perhaps the team that works the magic with OPNsense will take this into consideration.


Thank you all for your suggestions.

Alternatively you could use os-caddy as your DynDNS client with Cloudflare.

https://docs.opnsense.org/manual/how-tos/caddy.html#dynamic-dns-in-client-mode

Hi - Thanks. I tried that, but reached a limit of my knowledge of Caddy for use with Cloudflare. I put in the api key, and added two additional fields--email address (used for login with the API token) and base domain. It didn't work, but I'm sure I was doing something wrong. (I followed the rest of the instructions found in the link you'd provided; it mentioned none of these other things.)

With that said, I removed the configuration items I'd added in the GUI, and disabled Caddy through the UI. I then removed the package.

Now, the DDNS service won't even start if using ddclient versus native. (Native continues to throw the same errors.) Although not really a step backwards since it didn't work anyway, but another problem tied to this.

The original configuration should have worked without issues after implementing 24.7. In my case, I installed 24.7 fresh, updated, and then restored my configuration. I did it this way to avoid problems like this. I'm now wondering what else is wrong that I've not yet discovered across my implementation.

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 just found this thread via a search, after seeing the "legacy" notation in OpenVPN on OPNsense. The only thing I can say is that the current documentation is so awful, and the UI in OPNsense so bad, it leaves users in a situation where they will at some point be forced to spend a significant amount of time to "migrate" to the new instances. Seriously, I can't express how bad the documentation is. As an example, there is a network diagram with IP addresses (ALL private, I'll add) and a table later in the document that displays IP addresses that are not anywhere in the network diagram. (Or earlier descriptions.) It's not only amateur, it's sloppy and wrong.

I've yet to find any meaningful reason (defined as a justification as to why anyone would devote time to this) why the change to "instances" is on the roadmap at all. Though it should be obvious, I will bet that it is a very, very small set of individuals that are going to want to spend a significant amount of time trying to understand the "new way." The "old way" worked. But at some time it will not. For anyone who uses this functionality frequently, the looming death knell is far from comforting.

What a disaster.

The lack showing the IPv6 WAN delagated prefix is bad drop in my mind. WHY would that have been taken away? I cannot think of one good use case that would justify its removal...unless OPNsense is trying to mimic pFsense.

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.)

This is still a problem, as of 1.16.1. Understanding that this may be a version issue with Elasticsearch, 8.X and later is their latest version. (I think 8.12 is the latest as of this post's date.) Given the initiatation date of this thread, and the time that has elapsed, I'm surprised this has not been resolved.

If it is known not to work with certain versions of Elastic search, it should be checked prior to moving forward with the "external Elasticsearch" option. Worst case, don't provide the option. For individuals that are implementing Zenarmor for the first time, there will be time wasted trying to understand what is wrong--why certain reports do not display. It seems like a better solution to fix the defect, or prevent installation on a version that is known to not work correctly. Had I not stumbled on this thread (and it wasn't easy to find in a search), I would have continued to scratch my head and waste time.

Like others, I have a fundamental dislike of having my firewall/router also serving as a reporting database server.

Damn ISPs...  :)

My ISP fun is their changing my IPv6 prefix delegation randomly. Plays heck with my network, as I do not have the option of going SLAAC only due to the inability to block inter-VLAN IPv6 hosts but allow others through.

Glad you're up and running.

Uhm, no.

You have two rules on LAN for outbound traffic
- allow local networks
- block NOT Geo_US_Canada

You have one rule on WAN for inbound traffic (block NOT Geo_US_Canada).

Yep. This.

Related to blocking scanning on inbound, most serious threat actors tunnel through a country-local address--either through a VPN or TOR exit node. With that said, I believe that the country block rule will prevent access through an open port from countries in that alias, not prevent the scanning of open ports. I could be wrong about that, though. I could be just blowing smoke out my...foot.

Curious why direction is "out" on your last rule. Also, it might help to just explicitly block the countries for the purpose of troubleshooting instead of using an inverted rule. (I think I only have one inverted rule on my interfaces, and that correlates to accessing private IPs across VLANs.)

So, direction is in, block source is any, destination is the Geo_US_Canada alias. Pretty things up later.

The short answer is no. There is an article here: https://forum.opnsense.org/index.php?topic=29151.0 that talks about this. In my implementation, I found a different result. I found the file here: /usr/local/etc/ntopng.conf

I had to ssh to OPNsense, edit the file, and then restart the ntopng service. Stopping and starting the service, curiously, overwrote the file with the default (single) interface. Every time OPNsense restarts, an edit of that file is needed. Candidly, I think it's silly that OPNsense does not allow a multi-select on that field in the UI; I'd almost say it is a bug.