Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - surly

#1
I may have found something helpful in my case.

For EasyDNS, anyways, the problem may be that ddclient as configured in OPNsense uses a min interval of 5 minutes and EasyDNS API complains back that it wants a minimum interval of 10 minutes.  I'm not sure what started the first string of errors in the very first place, but now it seems stuck in a loop where every 5 minutes it tries to update because the previous failed, and the failure may be due to the unknown status (unknown to ddclient anyways) that I should only send updates every 10 minutes or more. 

The logs show attempts and failures with "unknown status" every 5 minutes.  So it considers that a failure and tries again in 5 minutes, but the "failure" is due to a message that ddclient is trying too often.

Could a knob be added to the opnsense config screen to set the minimum interval / max frequency?  Is this the "-daemon <delay>" option?

EDIT: was overlooking the interval setting on the general tab.  Changed that to '700' in my case to continue testing.
  Still believe that ddclient should understand the TOO FREQ error - leaving issue in place.


<29>1 2023-03-10T23:45:11-05:00 OPNplenum ddclient[16714] 31563 - [meta sequenceId="1"] FAILED:   updating <REDACTED1>: unexpected status (9d)
<29>1 2023-03-10T23:45:11-05:00 OPNplenum ddclient[16714] 32911 - [meta sequenceId="2"] FAILED:   updating <REDACTED2>: unexpected status (9e)
<29>1 2023-03-10T23:50:12-05:00 OPNplenum ddclient[16714] 82372 - [meta sequenceId="1"] FAILED:   updating <REDACTED1>: unexpected status (bb)
<29>1 2023-03-10T23:50:12-05:00 OPNplenum ddclient[16714] 83451 - [meta sequenceId="2"] FAILED:   updating <REDACTED2>: unexpected status (ba)
<29>1 2023-03-10T23:55:12-05:00 OPNplenum ddclient[16714] 18466 - [meta sequenceId="1"] FAILED:   updating <REDACTED1>: unexpected status (9d)
<29>1 2023-03-10T23:55:12-05:00 OPNplenumn ddclient[16714] 19477 - [meta sequenceId="2"] FAILED:   updating <REDACTED2>: unexpected status (9e)


logging from running 'ddclient -V -force' manually:

RECEIVE:  HTTP/1.1 200 OK
RECEIVE:  Date: Sat, 11 Mar 2023 12:53:52 GMT
RECEIVE:  Server: Apache
RECEIVE:  Expires: Thu, 19 Nov 1981 08:52:00 GMT
RECEIVE:  Cache-Control: no-store, no-cache, must-revalidate
RECEIVE:  Pragma: no-cache
RECEIVE:  Set-Cookie: easydns_language=en_US; expires=Sun, 10-Mar-2024 12:53:52 GMT; Max-Age=31536000; path=/
RECEIVE:  Set-Cookie: EasyDNS_SID=REDACTED; expires=Sat, 11-Mar-2023 14:53:52 GMT; Max-Age=7200; path=/; domain=api.cp.easydns.com; secure; HttpOnly
RECEIVE:  X-Frame-Options: sameorigin
RECEIVE:  Content-Security-Policy: frame-ancestors 'self';
RECEIVE:  Vary: Accept-Encoding
RECEIVE:  Connection: close
RECEIVE:  Transfer-Encoding: chunked
RECEIVE:  Content-Type: text/html; charset=UTF-8
RECEIVE: 
RECEIVE:  bb
RECEIVE:  <HTML><BODY><FONT FACE="sans-serif" SIZE="-1">TOO_FREQ<br />
RECEIVE:  <hr noshade size="1">
RECEIVE:  Increase your time between updates for <REDACTED> to 600 seconds or more.<br />
RECEIVE:  </FONT></BODY></HTML>
RECEIVE:  0



The setting of <delay> from within opnsense may be a useful option, and workaround for a few problems including this one.  I'm guessing that the real problem here is that ddclient needs to be made to understand a "TOO FREQ" response from my particular API?  Of course whatever originally set it into this loop is still unknown.


EDIT: Issue #525 opened
#2
I did not realize at first, but the move from 22.7.11_1 to 23.1 (now at 23.1_2, will be 23.1.3 shortly) also broke ddclient updates to easyDNS for me.   (The beginning of logged errors matches my upgrade date)

<29>1 2023-03-11T07:17:11-05:00 OPNplenum ddclient[39675] 43033 - [meta sequenceId="10"] FAILED:   updating <REDACTED>: unexpected status (bb)


where the status code in brackets is different for every attempt to update.

I am a reasonably adept user, but not a programmer in the slightest, so I cannot "contribute code".  Don't have a github account either, so clearly not an adept user of that tool, but I'll see what I can do...
#3
I've checked - the vyatta / EdgeOS spoke site seems to be working fully.  The openWRT spoke site isn't resolving DNS for leases at its site from the other sites.  I'll poke around when I can.  Might just be an ACL on the openWRT end not responding to the hub OPN queries.
#4
I do have this working (although the feature isn't used often - hub systems accessing spoke systems by name).  The architecture has changed somewhat with an Adguard Home instance as the primary listener on the hub OPN port 53, forwarding to unbound running on hub OPN port 5553.  Both servers are configured with the forward rule for the spoke sites.

What I cannot find is whether I did anything special .  I've checked my diary and unbound config and don't see any fancy tricks like I had to do on dnsmasq at the spoke sites.  I'll keep looking to see how I sorted this out, or if a patch fixed it, or if I found some silly mistake I had made somewhere.
#5
I have no solutions, but as a data point I can offer that my install is not-so-simple and I'm not observing a memory leak in 22.1.2_1 at this point. 

My unbound is set to recurse all queries and use DNSSEC, it was loaded with the Steven Black blocklist.  I'm also running Sensei, OpenVPN and Wireguard, multiple physical and virtual interfaces, mdns repeater, ACME, Adguard (only recently), HAProxy, UPNP w/ ACLs (for game console only), dyndns (just switched to ddclient) and more.

I have found since going to 22.x RAM utilization is +10% compared to 21.x but it seems to be holding steady at ~3.3G out of the 8G available according to the dashboard.  As a matter of fact, "wired" RAM is slowly falling as uptime increases.

EDIT: system is an i5-3k Dell Optiplex 8GB RAM w/ ZFS root on single SATA SSD running an i340-T4 NIC.

#6
A little more digging...

It looks like config.xml records a pointer to the chosen DNSAPI (based on whatever is available in the GUI) plus configuration values for every one of the available options (whether they are used or not).  My guess is that if easydns was permitted in the GUI, then easydns entries would also need to become part of the config.xml (regardless of whether selected for use).

So - not sure if it's just a case of only certain DNSAPIs were selected by OPN developers to include based on anticipated demand(?) and there's not a whole lot to be done other than to request that additional DNSAPIs get GUI and config support? (or do it manually, or do outside of OPNsense using cron and my own scripts which will likely get nuked on upgrade)

          <dns_service>dns_nsupdate</dns_service>
          <dns_sleep>120</dns_sleep>


          <dns_autodns_user/>
          <dns_autodns_password/>
          <dns_autodns_context/>
          <dns_aws_id/>
          <dns_aws_secret/>
          <dns_azuredns_subscriptionid/>
          <dns_azuredns_tenantid/>
          <dns_azuredns_appid/>
          <dns_azuredns_clientsecret/>
          <dns_cf_email/>
          <dns_cf_key/>
          <dns_cf_token/>
          <dns_cf_account_id/>
          <dns_cloudns_auth_id/>
          <dns_cloudns_sub_auth_id/>
          <dns_cloudns_auth_password/>
          <dns_cx_key/>
          <dns_cx_secret/>
          <dns_cyon_user/>
          <dns_cyon_password/>
          <dns_da_key/>
          <dns_da_insecure>1</dns_da_insecure>
          <dns_ddnss_token/>
          <dns_dgon_key/>
          <dns_dnsimple_token/>
          <dns_doapi_token/>
          <dns_do_pid/>
          <dns_do_password/>
          <dns_domeneshop_token/>
          <dns_domeneshop_secret/>


#7
I'm seeking to reestablish wildcard certs through Let's Encrypt using the ACME client.   My DNS provider (and registrar) is EasyDNS.  On pfSense, EasyDNS was listed in the DNS challenge section as a provider and it just worked.  I think I had my wildcard cert established in under a minute of my first attempt.

OPNsense does not list EasyDNS as a DNS provider in the challenge set up.  When I migrated (21.1) I let it go to figure out later.  Later is now.

I'm no developer, but I've been a CLI guy for over 30 years, and from what I can see EasyDNS is included in the ACME client package OPN is using, and is present in both the examples and the running folders:

root@OPN:/usr/local/share/examples/acme.sh/dnsapi # ls -l dns_easydns.sh
-r-xr-xr-x  1 root  wheel  4426 Feb  4 00:53 dns_easydns.sh


root@OPN:/var/db/acme/.acme.sh/dnsapi # ls -l dns_easydns.sh
-r-xr-xr-x  1 root  wheel  4426 Feb  4 00:53 dns_easydns.sh


Searching has not led me to specific answers about easydns, nor have I had the right search terms to find a information speaking about how particular API clients might be enabled or disabled in OPN.   I have found others posting where the OPN GUI offers APIs which are not supported by the installed ACME (https://forum.opnsense.org/index.php?topic=18476.0) but that's the opposite of my issue (and I've seen comments not to do what the OP did in that thread).

Do I have any options here to get this DNS API working in a "clean" way, supported in config backups and across updates/upgrades? (like it did, and still appears to, in pfSense).   

If not "clean", I'm open to recommendations on the "least unclean" ways to do this automatically.

#8
Fixed, I think.  I have Unifi switching and AP.  Cycling the configuration in the "Block LAN to WLAN Multicast and Broadcast Data" section (contains a list of exception MAC addrs) has possibly fixed it.  All of the affected equipment had been rebooted without fixing it.

Using wireshark I had observed that that kids LAN was basically devoid of almost all MCAST traffic while on wifi.  Not even chatter amongst the various teen devices.  The LAN where castable devices reside was extremely active wired and wireless.  That made me go "hmmm", followed by "eureka".  I checked both settings related to client isolation and broadcast/multicast.

So long as this sticks and there isn't some weird interaction which confuses the Unifis, hopefully this is in the rearview mirror.
#9
Yes, I'll probably have to start sniffing.  Again, everything was settled and fine, the 22.1 upgrade with no other changes started it all.  Every switch in the house has been rebooted.  I'll have to keep chugging at it whenever time permits.

No 'out' rules are implemented anywhere except one on WAN to block a specific malware.  That's been in place for a few months.

I'm all ears for any ideas as to cause.
#10
Quote from: Mks on March 01, 2022, 07:02:25 AM
I had a similar issues. After restart of my managed switch it works again. I assume it was an issues with multicssts.

I was thinking something similar.  Switch reboots here have had no effect.
#11
Started manually with -f and everything looks fine, but it doesn't work.  Quite the flurry of activity when I restarted the shield and TV on the other LAN.  Constant chatter from the devices on the kids LAN.  mdns-repeater says it's doing all the right things in debug mode.

No changes were made to rules or anything else when the upgrade was done.  Initially I thought everything was OK, this and one other thing only revealed themselves later.   Since then I've reviewed and, if anything, made things more permissive with additional logging.

Many thousands of permits on the "permit multicast" rules on both networks.  Without any denied traffic and with good looking debug output I'm unsure where to go from here.   

Was thinking - I do use zenarmor on the kids interface too.  I shut down the packet engine, restarted mdns-repeater to test, no change.  I did not see dmesg indicating that it took the adapter out of promiscuous mode when stopped zenarmor though so it's not quite like it was never there.

The only other thing I noticed that was off was something with wireguard site-to-site. 
#12
OK - it's not everyone so that's "good'.  NIC is i340-T4 in an Optiplex i5-3xxx box..   Will keep looking at mdns debug modes.

Thanks
#13
Hi all:

Late last week I updated from 21.7 to 22.1.  I did an upgrade in place.  After some brief testing I did a reinstall with config import to move from UFS -> ZFS for the rootfs.   Again, other than having to separate restore zenarmor configs from separate backups everything seemed OK.

In more detailed use over the next couple of days I discovered a small handful of issues.  One is that mdns-repeater doesn't seem to be doing anything any longer.  I have - verified the config, checked that it's running, stop/start, enable/disable, uninstalled and reinstalled, rebooted firewall.  I don't see mdns-repeater logging anywhere on the system.

I have also exhaustively gone through all of the firewall rules which took me a fair bit of time to develop 18 months ago or so to allow a VLAN where my kids' devices are to cast to my entertainment devices on another VLAN.   All of the rules to allow traffic to flow between devices (printers, chromecasts, TV, AVR) seem to be working but anything requiring mDNS doesn't find anything to connect to.  On a test laptop Bonjour Browser is empty and google Chrome shows nothing available in the Cast-> function from the kid VLAN.  I see multicast traffic to UDP/5353 hitting "pass" rules on both interfaces.

One potentially different config I have that might be uncommon which arose due to the way my home LAN evolved - my main LAN is untagged and many other VLANs (including the kids) are tagged on the same physical interface.  i.e. the LAN with the devices I want to case to is on igb1 and those attempting to cast are on igb1_vlanX.  This worked prior to 22.1, zenarmor and other software is still working fine from what I can see.

Anyone else?
#14
22.1 Legacy Series / Re: Unidentified call to Google
February 19, 2022, 01:26:15 PM
"Me too", but it's "YouTube" for me.  Not sure when it started.

In my case it looks to be an alias in Firewall -> Aliases called "Youtube" of type "hosts" with a list of FQDNs that need to resolve.  So, this log makes perfect sense.  Although I don't recall creating this alias, but that doesn't mean I didn't.  It doesn't seem to be used for anything at the moment.

Check yours for a hosts alias called "Google" and that's likely your cause.  An alias with a list of FQDNs must be resolved to IP addresses on a regular basis to build the actual alias to use in the filters.
#15
OK understood.  I spent some time with google and the forum search and never hit anything quite describing my issue.  Sorry....  I guess the help text could mention this impact if nothing else?  I will leave this config option blank - so far so good.

Cheers