Messages

Trying to make the transition to the new os-ddclient in OPNSense 22.7.1 (OpenSSL) using CloudFlare with freedns and keep getting errors... The logs show:

Code Select Expand

46056 - [meta sequenceId="5"] WARNING: file /var/tmp/ddclient.cache, line 7: Invalid Value for keyword 'ip' = ''

Running the checkip command copied from the ddclient.conf works as expected returning my public ip address:

Code Select Expand

/usr/local/opnsense/scripts/ddclient/checkip -i fxp0 -t 1 -s freedns

but looking at the log file mentioned 'ip' is empty:

Code Select Expand

atime=1660498099,backupmx=0,host=<tld>,ip=,mtime=0,mx=,static=0,status=noconnect,warned-min-error-interval=0,warned-min-interval=0,wildcard=0,wtime=0 <tld>

UPDATE: I tried to force ddclient and get this:

Code Select Expand


WARNING:  file /var/tmp/ddclient.cache, line 3: Invalid Value for keyword 'ip' = ''
WARNING:  file /var/tmp/ddclient.cache, line 4: Invalid Value for keyword 'ip' = ''
WARNING:  file /var/tmp/ddclient.cache, line 5: Invalid Value for keyword 'ip' = ''
WARNING:  file /var/tmp/ddclient.cache, line 6: Invalid Value for keyword 'ip' = ''
WARNING:  file /var/tmp/ddclient.cache, line 7: Invalid Value for keyword 'ip' = ''


How do I go about fixing this?

Is there a path to get this release added to the OPNsense plugins (or whatever the appropriate description is) library (or get the plugin modified to use the release version instead of 3.9.1)

[SuperSandro2000]

I ran the patch again, got the following in the console, and can now see the Service entry in the list:

Code Select Expand


Found local copy of 33999368, skipping fetch.
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|From 339993680de4453962d21546a181550bd1cc0f0f Mon Sep 17 00:00:00 2001
|From: Ad Schellevis <ad@opnsense.org>
|Date: Fri, 24 Jun 2022 20:11:31 +0200
|Subject: [PATCH] dns/ddclient - validate statistics before usage to prevent
| missing fields, for now let's assume mtime is always filled, ip apparantly
| isn't. ref https://forum.opnsense.org/index.php?topic=28835.msg140355
|
|---
| dns/ddclient/Makefile                                           | 1 +
| .../mvc/app/models/OPNsense/DynDNS/FieldTypes/AccountField.php  | 2 +-
| 2 files changed, 2 insertions(+), 1 deletion(-)
|
|diff --git a/dns/ddclient/src/opnsense/mvc/app/models/OPNsense/DynDNS/FieldTypes/AccountField.php b/dns/ddclient/src/opnsense/mvc/app/models/OPNsense/DynDNS/FieldTypes/AccountField.php
|index 24d856e99e..b11bcaf7c0 100644
|--- a/dns/ddclient/src/opnsense/mvc/app/models/OPNsense/DynDNS/FieldTypes/AccountField.php
|+++ b/dns/ddclient/src/opnsense/mvc/app/models/OPNsense/DynDNS/FieldTypes/AccountField.php
--------------------------
Patching file opnsense/mvc/app/models/OPNsense/DynDNS/FieldTypes/AccountField.php using Plan A...
Hunk #1 succeeded at 50.
done
All patches have been applied successfully.  Have a nice day.


In Github issue 361 https://github.com/ddclient/ddclient/issues/361 ddclient 3.10.0 is being recommended for install by SuperSandro2000 in response to https://github.com/ddclient/ddclient/issues/361#issuecomment-1149646988.

The releases page (https://github.com/ddclient/ddclient/tree/release/release-3.10.0)shows that it has been built / uploaded to FreeBSD.ports.

can you try https://github.com/opnsense/plugins/commit/339993680de4453962d21546a181550bd1cc0f0f ?

To install via a console, use the following command:

Code Select Expand


opnsense-patch -c plugins 33999368


the /var/tmp/ddclient.cache  file likely contains incomplete data.

Best regards,

Ad

(FROM: https://github.com/opnsense/plugins/issues/3019)

Thanks AdSchellevis,

Running the patch (at the visible level) had the temporary effect of making the entry visible.
There were no errors displayed, and it didn't look like there was a need to add / change anything.

Now, several minutes later I am getting this:

An API exception has occured
/usr/local/opnsense/mvc/app/controllers/OPNsense/Base/ApiControllerBase.php:152: Error at /usr/local/opnsense/mvc/app/models/OPNsense/DynDNS/FieldTypes/AccountField.php:55 - Undefined index: ip (errno=8)

Secondarily: I keep seeing that the GUI doesn't support CloudFlare tokens (and tried to use one here), do you know if that is that still true?

Also, it seems like you told us to install a patch without telling us what it was or why we needed it... I chose to trust your input, but it would be great to know why you are recommending the patch and what you expect it to do (to help make sure it works and to establish expectations)

While the original report is not resolved I now have a working firewall by using the VGA installer, I was never able to get the ISO.bz to not give an error.

To bypass the install freeze I wiped all partitions on the drive (Possibly not needed), choose the 3rd option on the install menu (not UFS or ZFS) > Picked guided > Picked my Drive > and then told it to take the whole drive.

Everything went smooth after that with the exception that it didn't create a UEFI boot entry in the BIOS, I removed all the entries that were there, created a new one, accepted default values, then browsed to the efi\boot\ and loaded the efi file available there... OPNSense then booted as expected.

@mb thanks for your reply!

I have no idea what that is, I am on Cable Internet, and have RealTek and Intel NIC's in this machine.

[OPNsense-21.7-OpenSSL-dvd-amd64.iso.bz2]

I have downloaded the OPNsense-21.7-OpenSSL-dvd-amd64.iso.bz2 from all 3 US Mirrors and when I try to "burn" the image to my flash drive I get the following errors:

Rufus:
This image is either non-bootable, or it uses a boot or compression method that is not supported by Rufus...

belenaEtcher:
Missing partition table
It looks like this is not a bootable image.  The image does not appear to contain a partition table, and might not be recognized or bootable by your device.

I downloaded OPNsense-21.7-OpenSSL-vga-amd64.img and successfully burned it, but then the UFS installer shows the cursor block and stalls or infinitely waits (unless you connect / disconnect a device or connection like the ethernet or USB installer disk)

I think there is some issue with OPNsense DHCP client service.

I agree with this sentiment, although I have yet to figure out what to change to resolve that issue... Again, it seems to be a routing / translation issue.

[Check IPv6:]

Just another ProxMox + OPNSense + DOCSIS user here...

I have had this issue as well, still looking for a long term solution.

The most productive settings I have found so far:

• Uncheck the "Block private networks" box for the WAN Interface (DOCSIS -> OPNSense WAN).  The surface level symptoms I have seen make me think there might be a bug involved where it either fails to detect valid IP addresses (www.xxx.yyy.zzz) or times out.
• Check IPv6: Many service providers have begun to standup IPv6 connectivity but routing is not correctly configured, when I stopped allowing IPv6 to be used by services most of my issues with the DOCSIS went away.

[Edits:]

Please upgrade rather than downgrade :-)

New Unbound version (1.13.0) was released to deal with CVE issues, patch (1.13.0_1) is minor and keeps those improvements:

Here's the latest Unbound revision 1 from FreeBSD ports to try:

# pkg add -f https://pkg.opnsense.org/FreeBSD:12:amd64/20.7/misc/unbound-1.13.0_1.txz

Edits: Include version and package information

[FWIW:]

Just another OPNSense user here...

• FWIW: There is a reported issue with Unbound DNS for some users here:
          https://forum.opnsense.org/index.php?topic=20516.0, a patch has been released:
  
     

  
      Here's the latest Unbound revision 1 from FreeBSD ports to try:
     
      # pkg add -f https://pkg.opnsense.org/FreeBSD:12:amd64/20.7/misc/unbound-1.13.0_1.txz
     

  
  If you have upgraded and are using Unbound I would start here as it will have the least (potential) negative impact.
  
  


• When we started the quarantine for COVID and I had to start working from home I ran into an issue like this where there was so much traffic that DNS requests were being delayed (and in some cases timing out).  To resolve this I setup traffic shaping that ensures that important traffic (like VOIP and DNS requests) always have a VIP lane to communicate with.  Since turning this on I have had no further issues, there is a helpful HOW-To here: https://docs.opnsense.org/manual/how-tos/shaper.html

Good luck!

That was my experience as well after the upgrade, in my case the hard shutdown and reboot fixed the majority of my issues.

I saw this in the post discussing unbound issues:

Please check the interfaces it is listening to. Maybe there is something wrong. Change this setting and hit save. Then change it back and save again.

I have had issues in the past with the WAN connection losing its place and refusing to get a new IP (I am on a dynamic IP service) and swapping the interfaces (or setting the WAN the same interface as the LAN long enough to save, refresh the page and then swap back) fixed those issues.

[Edit(s):]

The 20.7.7 version of Unbound (1.12.x) had a bug that causes the Unbound DNS service to crash repeatedly (Apparently only for some users) there is a patch released by unbound that seems to resolve the issue.

Patch command: pkg add -f https://pkg.opnsense.org/FreeBSD:12:amd64/20.7/misc/unbound-1.13.0_1.txz

Honestly, I am not sure this is your issue, but this patch is so minor it should only help.

Edit(s): Fix finger wandering issues

Just another OPNSense user here... Any reason why you don't want to just patch up to the newest version - Created by unbound to address this issue?

Here is the command: pkg add -f https://pkg.opnsense.org/FreeBSD:12:amd64/20.7/misc/unbound-1.13.0_1.txz

Per Franco: This patch is minimal

I was able to upgrade without rebooting the server, although I had to hard shutdown the server after the "broke" version installed to get my system to respond to commands via WebGUI or VM shell. 

[OPNSense Version:]

OPNSense Version:OPNsense 20.7.7_1-amd64 (and previous)
[freeBSD Version:[/b] FreeBSD 12.1-RELEASE-p11-HBSD
Hypervisor: Proxmox (6.3-3) - and previous

I have been having issues for a while with OPNSense not responding to reboot / shutdown requests from the hypervisor via ACPI calls, I have been working around it by logging into OPNSense via the WebGUI, but yesterday (after I upgraded to 20.7.7) the web GUI stopped responding, the vm shell console, and internet access went down repeatedly forcing me to down the entire server to force OPNSense to reload.

While trouble shooting I followed a guide from Proxmox for Linux VM's that basically said to make sure acpi was installed & running.  Since ACPI is included in FreeBSD core I thought it would be quickly resolved.  I followed this page: https://www.freebsd.org/doc/handbook/acpi-overview.html to verify that terminal acpiconf calls responded in a useful way (they did), however, OPNSense is not reacting to calls from the Hypervisor.

Other VM's (Debian) on the same server respond without issue, how can I troubleshoot the communications for this VM?  :-\ :-\ :-\