DNS and Package Displays, again.
-
Posting here because I've been working (off and on) on a new 1100 since October and over 2 versions of firmware, so it seems I've got an installation problem. Netgate newbie.
V23.01-RELEASE (arm64) and 22.05.
I can't display available packages and sometimes I can't even display installed packages. Many of the posts refer to "You messed up DNS" and "pfSense uses SRV records". I feel like the following shows I don't have a DNS problem.
<snip>
[23.01-RELEASE][root@my.mydomain.com] /root: host -t srv _https._tcp.pkg.pfsense.org
_https._tcp.pkg.pfsense.org has SRV record 10 10 443 pkg00-atx.netgate.com.
_https._tcp.pkg.pfsense.org has SRV record 10 10 443 pkg01-atx.netgate.com.
<snip>On pfSense I log into a PPPoE connection to CenturyLink DSL, I manually enter various combinations of the Quad 9 and Cloudflare DNS, and I am using DNS Resolver, not DNS Forwarder. Checked or uncheck, this has no bearing: "DNS Server Override". Also, I have left the DNS configuration blank. At no time other than fetching packages does DNS fail me.
The next major theme in the forum has to do with my package database. See above, reaching the repository isn't a problem, but I'm failing to authenticate. I have no clue where the creds I must be passing along are or where they came from. These are fresh installs of the last two versions of firmware and I have made no changes.
<snip>
root: /usr/local/sbin/pkg-static update -f
Updating pfSense-core repository catalogue...
pkg-static: https://pfsense-plus-pkg00.atx.netgate.com/pfSense_plus-v23_01_aarch64-core/meta.txz: Authentication error
repository pfSense-core has no meta file, using default settings
pkg-static: https://pfsense-plus-pkg00.atx.netgate.com/pfSense_plus-v23_01_aarch64-core/packagesite.pkg: Authentication error
pkg-static: https://pfsense-plus-pkg00.atx.netgate.com/pfSense_plus-v23_01_aarch64-core/packagesite.txz: Authentication error
Unable to update repository pfSense-core
Updating pfSense repository catalogue...
pkg-static: https://pfsense-plus-pkg00.atx.netgate.com/pfSense_plus-v23_01_aarch64-pfSense_plus_v23_01/meta.txz: Authentication error
repository pfSense has no meta file, using default settings
pkg-static: https://pfsense-plus-pkg00.atx.netgate.com/pfSense_plus-v23_01_aarch64-pfSense_plus_v23_01/packagesite.pkg: Authentication error
pkg-static: https://pfsense-plus-pkg00.atx.netgate.com/pfSense_plus-v23_01_aarch64-pfSense_plus_v23_01/packagesite.txz: Authentication error
Unable to update repository pfSense
Error updating repositories!
<snip>Any useful advice is appreciated. I can reproduce command output or provide the file screenlog.o. If I've missed something in the dox, feel free to gloat, AFTER you show me what I missed.
TIA
-
@securityguy32 Did you reinstall 23.01 via
usbrecoverymethod?
Had a 1100 last week that tried upgrading from 22.05 that bricked, reinstalled with usbrecovery and the thing is running smoothly ever since. So it does somehow seem related your config. The authentication errors seem strange to me though. Did you check System / Updates for the 23.01 repository? Does it show up and is selected? As there were quite a few posts now with boxes that weren't "registered" after updating to 23.01, just want to check if the package repository itself is fine? -
@jegr @jegr Thanks for the reply.
I installed firmware updates by dd'ing the new image from Netgate onto a USB, opening a console to the router, booting, and yes, running usbrecovery at the Marvell prompt. I used the steps as described in the documentation. I've done it multiple times with both firmware versions. This error won't change. I did it this way because I've never yet seen an option in the Upgrade window. Since new purchase in October with 22.05 installed, I've had the same scenario as below.
As for update, and I still don't quite understand the relationship between and update and package retrieval, but as of now I'm on 23.01. Conceivably I could go back to the 22.05 and gather evidence, but I'm not making changes to the factory settings so I don't expect to find anything of value. I can check my notes, and if I can't find anything, there may be value in reflashing 22.05 and gathering the error messages when I try to update from the menu in console. System/Update/System Update shows the current version only. Drop down window is null. The gear turns and stops at Unable to Check for Updates. This can take only seconds, it can go for hours and never complete. My gut says the choice of those words means "You can't reach a repository", not, "There are no updates available because you are on the latest." I suspect that it is why people call out DNS but I feel I have ruled that out as documented in the thread. If I'm reading my host command output wrong, please advise.
I too had seen that the repository had been paused for the 1100, but I think it is restarted. Regardless, my problem existed before the repository was paused.
Is there a concrete way to see whether my device is registered other than inference from the presence or absence of 22.05 in my upgrade drop down?
-
@jegr I got curious and recreated more evidence, this from the console of the current 23.01. The errors look very much like the package errors.
root@oscar:~# tail -65 screenlog.0
WAN (wan) -> pppoe0 -> v4/PPPoE: xx/32
LAN (lan) -> mvneta0.4091 -> v4: 192.168.1.1/24
OPT (opt1) -> mvneta0.4092 ->- Logout (SSH only) 9) pfTop
- Assign Interfaces 10) Filter Logs
- Set interface(s) IP address 11) Restart webConfigurator
- Reset webConfigurator password 12) PHP shell + Netgate pfSense Plus tools
- Reset to factory defaults 13) Update from console
- Reboot system 14) Enable Secure Shell (sshd)
- Halt system 15) Restore recent configuration
- Ping host 16) Restart PHP-FPM
- Shell
Enter an option: 13
ERROR: It was not possible to determine pfSense-u-boot-1100 remote version
Migrating /var/cache/pkg to ZFS dataset pfSense/ROOT/default/var_cache_pkg... done.
ERROR: It was not possible to determine pkg remote versionUpdating repositories metadata...
Updating pfSense-core repository catalogue...
pkg-static: https://pfsense-plus-pkg00.atx.netgate.com/pfSense_plus-v23_01_aarch64-core/meta.txz: Authentication error
repository pfSense-core has no meta file, using default settings
pkg-static: https://pfsense-plus-pkg00.atx.netgate.com/pfSense_plus-v23_01_aarch64-core/packagesite.pkg: Authentication error
pkg-static: https://pfsense-plus-pkg00.atx.netgate.com/pfSense_plus-v23_01_aarch64-core/packagesite.txz: Authentication error
Unable to update repository pfSense-core
Updating pfSense repository catalogue...
pkg-static: https://pfsense-plus-pkg00.atx.netgate.com/pfSense_plus-v23_01_aarch64-pfSense_plus_v23_01/meta.txz: Authentication error
repository pfSense has no meta file, using default settings
pkg-static: https://pfsense-plus-pkg00.atx.netgate.com/pfSense_plus-v23_01_aarch64-pfSense_plus_v23_01/packagesite.pkg: Authentication error
pkg-static: https://pfsense-plus-pkg00.atx.netgate.com/pfSense_plus-v23_01_aarch64-pfSense_plus_v23_01/packagesite.txz: Authentication error
Unable to update repository pfSense
Error updating repositories!
ERROR: It was not possible to determine pfSense-upgrade remote version
ERROR: It was not possible to determine pfSense-upgrade remote version
Upgrading pfSense-upgrade... failed. -
FEEXED: I won't claim to understand all I know about it, but ....
The accidental solution was a serendipitous change of ISP. I moved from a hardwire DSL from Century Link to a trial offer of 5G cellular from T-Mobile, et voila!. Netgate glides through paces, USBRECOVERY installs various versions, upgrades from console and GUI, package installs from console and GUI, speedtest-cli from the console, and the router is running ProtonVPN at the above speeds.
Downloads are ~6x, and uploads are ~55x, the speed of my DSL "service". Currently trying to secure it all from T-Mobile and their breaches du jour. FWIW, the price of both ISPs is the same and no contract.
-
Thanks for the feedback.
@securityguy32 said in DNS and Package Displays, again.:
USBRECOVERY installs various
You've changed your ISP and you've re installed pfSense ?
That somewhat stops me from serious finger pointing to your old ISP.But, true, there are ISP out there that 'do things' with 'some' internet packets.
That's one of the reasons why "DNS Forwarding" exists, instead of the default resolver mode. An ISP should give you access to the main '13' internet root servers, and the thousands of tld servers. Thus resolving would work fine.@securityguy32 said in DNS and Package Displays, again.:
Many of the posts refer to "You messed up DNS"
I plaid guilty.
jimp has put my record straight lately, as he pointed out that an internet access isn't always that neutral and perfect as I was thinking. So, some popel have to forward to 1.1.1.1 8.8.8.8 9.9.9.9 etc.You still messed up, of course
by choosing an ISP that didn't fit your needs.When you see this :
@securityguy32 said in DNS and Package Displays, again.:
pkg-static: https://pfsense-plus-pkg00.atx.netgate.com/pfSense_plus-v23_01_aarch64-pfSense_plus_v23_01/packagesite.pkg: Authentication err
it tells me that pfSense upgrade servers were reached.
So : DNS was ok.
These Netgate servers said 'go away' because of an "Authentication err". Details of this auth err can be found on the forum.
It's something like : no valid cert, date/time not ok, or Netgatde devcie ID not recognized. -
@gertjan Thanks gertjan. It seems we are at the same understanding. DNS was never the problem, it was authentication in some way shape or form. That is why I had asked for some discrete way to determine what creds I was sending and/or how to determine my registration status. I still don't know where the creds are and why it all works now. Still, as stated, I had installed both versions from the console and virgin installs had the same authentication problem. Clearly it wasn't something I did as I had done nothing. The one change that made it all work was to change ISP. We can conclude that is the difference that worked, but we have no way to determine if it works because CL isn't manipulating something or TM is manipulating something. Like I said, I don't understand everything I know.
At this point I'm moving to a more important problem. There is urgency only because my ISP account is a trial period with a company known for breaches. My LAN segments are all routed to my ProtonVPN and traceroute from the LAN shows that I go to my virtual address, then my Proton, then the open Internet. HOWEVER, a traceroute from the console command shell goes out the WAN directly to the ISP. I have to allow the ISP to send me DHCP (write) but I see no reason to allow other writes and any reads at all.
I'll be in the documentation for the foreseeable future.
PS. I am aware that TM breaches are customer account PII data and I've ensured that if they leak what they have I won't be concerned. However, any company run this way is suspect as to what they may try, or inadvertently allow, over my WAN connection.
