Messages

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.

If I have block private address enabled on WAN would that cause an issue?  My CM is doing the same thing based on the logs.  Its giving the 192.168.100.x addressing and since that is a private address its blocked on the WAN.  From the logs it appears as if the ethernet cable from the WAN is being unplugged.  It shows DOWN and then 6 seconds later shows UP.  Then 5 seconds later the dhclient throws an error "connection closed".

When I login to my Arris CM I see this in the event logs around the same time:
Thu Jan 01 00:01:44 1970   3   No Ranging Response received - T3 time-out;CM-MAC=[REMOVED];CMTS-MAC=[REMOVED];CM-QOS=1.1;CM-VER=3.0;

It looks like my cable modem is rebooting.  Uptime on the web interface for cable model shows uptime of 16h.

I'm not sure what you mean by a block of Private IP addresses on the WAN. They are generally blocked by default, unless you de-selected that option for the WAN interface. I have blocked them on my WAN interface, as well as BOGONS. Although private IP addresses aren't routable on the Internet, it's still a good security measure to leave the box checked.

Your ISP can reboot your modem as well. I don't use an Arris modem (nor am I on Comcast), but I'm relatively sure there is nothing in the modem that tells it to reboot every 24 hours. I'm reaching here, as I do not have direct knowledge of how Arris and/or Comcast work--it could be that a renew initiates a modem reboot. Mine does not do that, but it's really apples/oranges.

Do you own the modem, or is it theirs? I bought my own because I hated the Spectrum-provided modem. (It failed to indicate an outage when there was one, and when it boots it isn't only time to get coffee--it's literally drive to Pete's/Coffee Bean/Starbucks to get the coffee...it was that long.

My guess would be DHCP as well. Out of curiosity, I searched to see if there was a way for you to see how long the lease was for your DHCP address on the WAN interface. I did find the following that might help you troubleshoot it a bit more: https://www.reddit.com/r/opnsense/comments/xphlfp/is_there_a_way_to_check_wan_uptime_or_dhcp_lease/

What I've seen on a DHCP WAN renewal is that the WAN interface changes to the private IP on your modem (for my brand it's 192.168.100.1) and then eventually changes to the assigned IP from your ISP. I didn't dig into your log enough to see if that is what was happening.

Hi, I replicated the firewall rules (with interface changes) from another working interface. (With the obvious changes to reflect the interface to which the rules were on.) The rules added were specific to Internet access and DNS.

With that said, I'm unaware of any rules needed on an interface to merely allow devices to obtain an DHCP address. Even if I assigned a static address on the device, it didn't work. From the time I rebooted OPNsense and the time it came back up, I made no changes to rules, interfaces, DHCP, etc. It just started working. It would seem that if it was a rule problem it would have been the same before and after the reboot absent changes.

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