Unable to retrive package information

wbptls

Running pfsense 2.4.5(latest stable) on a vm, it errors out saying "unable to reterive package information" tried the pkg upgrade pkg command it errors out aswell. how do i resolve this ? wan/net runs fine otherwise so this does not seem to be a connectivity issue.

Screenshot from 2021-02-02 22-51-21.png

stephenw10

Looks like a DNS issue. Can pfSense resolve other sites:

Try running pkg -d update to get more error info.

Steve

wbptls

@stephenw10 This worked,thank you.
changing the dns from Pihole to the inbuilt dns resolver worked. Pihole did not block the request before but the dns set on it for some reason failed to resolve the address upstream.

Gertjan

@wbptls said in Unable to retrive package information:

some reason failed to resolve the address upstream.

Your pihole resolves ?
If it fails, this means that your up stream connection is bad - was bad at that moment.
There are many DNS root servers, many TLD, and pfsense.org has several name servers.
So, the Internet was broke as a whole ... or your upstream ^^

Still, better check this. your pi hole has logs : what happened when "pfsense.org" was asked to be resolved ? You have your answers right away.

pi-hole -forwards to some other resolver ?
Well...... You get what you pay for ^^

stephenw10

Remember is uses SRV records: https://docs.netgate.com/pfsense/en/latest/troubleshooting/upgrades.html#pkg-pfsense-org-has-no-a-aaaa-record

Steve

wbptls

@stephenw10 @Gertjan pfsense does not show up on the query log of pihole. why this might be happening ?

stephenw10

Try running the test commands shown in that doc:

[2.4.5-RELEASE][root@2100-3.stevew.lan]/root: host -t srv _https._tcp.pkg.pfsense.org
_https._tcp.pkg.pfsense.org has SRV record 10 10 443 files00.netgate.com.
_https._tcp.pkg.pfsense.org has SRV record 10 10 443 files01.netgate.com.

Gertjan

@wbptls said in Unable to retrive package information:

why this might be happening ?

Use the pfsense console acces and :

dig _https._tcp.pkg.pfsense.org SRV +short

Is the answer :

10 10 443 files00.netgate.com.
10 10 443 files01.netgate.com.

edit : lol. Two methods for the same test.

wbptls

@gertjan @stephenw10 it seems to have resolved after i had pihole point back to the pfsense and use that as a dns. I will replicate the pihole as a dns setup though and get back by trying the above commands to see the output and what exactly might be the bug here causing everything to resolve except pfsense/netgate.

wbptls

@Gertjan @stephenw10 this is what i get after running the commands,the irony of the situation is internet works fine on other devices except for router providing the internet. I have set pihole as my dns,everytime i set dns as my pihole through dhcp server settings this happens for some reason. pihole uses cloudflare as dns

Screenshot from 2021-02-09 23-06-30.png

Gertjan

@wbptls

I was using the +short option to show you that my 'DNS path' works.

You want answers, so have dig present them to you :

dig _https._tcp.pkg.pfsense.org SRV +trace.

It's a long story : from top to bottom :

[2.4.5-RELEASE][root@rack2.inner-core.local]/root: dig _https._tcp.pkg.pfsense.org SRV +trace

; <<>> DiG 9.14.12 <<>> _https._tcp.pkg.pfsense.org SRV +trace
;; global options: +cmd
.                       62835   IN      NS      h.root-servers.net.
.                       62835   IN      NS      j.root-servers.net.
.                       62835   IN      NS      k.root-servers.net.
.                       62835   IN      NS      b.root-servers.net.
.                       62835   IN      NS      d.root-servers.net.
.                       62835   IN      NS      e.root-servers.net.
.                       62835   IN      NS      g.root-servers.net.
.                       62835   IN      NS      f.root-servers.net.
.                       62835   IN      NS      a.root-servers.net.
.                       62835   IN      NS      i.root-servers.net.
.                       62835   IN      NS      m.root-servers.net.
.                       62835   IN      NS      l.root-servers.net.
.                       62835   IN      NS      c.root-servers.net.
.                       62835   IN      RRSIG   NS 8 0 518400 20210222160000 20210209150000 42351 . D+QwrUNryZwoc1VCPLaVWa3MZGjHi/Y2/MD6eJCchN289JD+6KcT4zHo s+df8O+fTyETRFZarI+0Ggm/InVvjvWeBYVRBTSoPD6/oR7fzBIhDY6h QnIQe0ldaa/6B16y178I/6tTlSYyEYdjxKZk7/LI82903I4Wbaj8T9Ns xginxb4s8DdG0iSXZCva6Zzd01FUFpYY+3t+ZKp/xTVeyIQpHq9d5ugi M7Oc/xivwM8zKrj1oXvMsxiMMAfO6vWggyrjG+C0HocEjM+EF7TLkFMg +6bHda/3wThTGU9M3fo/pWyiOJlQ+zT5tRS8m/F3ZpufA6Am7UpwycQI wLySZQ==
;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 3 ms

org.                    172800  IN      NS      b0.org.afilias-nst.org.
org.                    172800  IN      NS      a2.org.afilias-nst.info.
org.                    172800  IN      NS      c0.org.afilias-nst.info.
org.                    172800  IN      NS      d0.org.afilias-nst.org.
org.                    172800  IN      NS      a0.org.afilias-nst.info.
org.                    172800  IN      NS      b2.org.afilias-nst.org.
org.                    86400   IN      DS      26974 8 2 4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32
org.                    86400   IN      RRSIG   DS 8 1 86400 20210222170000 20210209160000 42351 . lk331ZyFN1Qp1BMjbTKc9q6GnwpEK74qHrQk9kGs+R4XY/wYmY9MDEZ3 KmtzhzBDQPnjK/ye1U7t29ejNl5pdSrmmdfAmYNegNwAcQg8yomAtOrK vUk30lBh/9WXeHibYMPyyCcTljrQcPMkvy2HuAVE7m++jLc37mMIp2or gh4Y+S0V6GOVNBTvuubXVhU9ybK6KjEPHGxyZHEfK+xlMjGX+VprChdN 11eg5f21VroZ+7yR+estVgkkdcgbILNeiriMJHvaihBYe0NNq0N1MMYi CDV6Dvj9/p/E3n9Qsdj39QXPPS4JkN9M5cylbh9UmdZfZKmCeVig+lmL kwA8BA==
;; Received 799 bytes from 2001:7fd::1#53(k.root-servers.net) in 49 ms

pfsense.org.            86400   IN      NS      ns1.netgate.com.
pfsense.org.            86400   IN      NS      ns2.netgate.com.
d6n22mffurrkkhup4jscmntse266m0lq.org. 86400 IN NSEC3 1 1 100 332539EE7F95C32A D6N6GR81BV9D3CE1VSG6FN5BAU7UB671 NS SOA RRSIG DNSKEY NSEC3PARAM
etu38qs0hb80br1fagq9s4m2tdb10jlm.org. 86400 IN NSEC3 1 1 100 332539EE7F95C32A ETUDVE7KU01VF5A7EP2AA8DNS5H5PR4J NS DS RRSIG
d6n22mffurrkkhup4jscmntse266m0lq.org. 86400 IN RRSIG NSEC3 8 2 86400 20210302232417 20210209222417 34266 org. mgqUtMmYrEDRNLmAjKqMMMZ/3RxiZY+M5eJZ9x63e5TKZnWBS/Gbq/Nm l8hbOe9DSWYNI4F7AKBdaEfquIBBVuXlXOx85PBXb7LFMReB96KZxMjB JmBu+hlstK8B8sjo2j/p42uA8vSmQVyhqj9K677W/A3iq9SRwX9jS8zS XtA=
etu38qs0hb80br1fagq9s4m2tdb10jlm.org. 86400 IN RRSIG NSEC3 8 2 86400 20210302153257 20210209143257 34266 org. KC0ZEBowV3XJ/qnbPO7bP8LQMIpPUNA24dq8T64quCNNLuTe/FESlSGl cRiPaGItDM/TBU57yL/I1EttV1s11zaviegi6jJ9CQQs4VMR4EBdjsqq g9f8UhC6es8O3X1dE/m1z0O9KLFmr4lGJz5mTIwYiBGjCmXQDjeOVhZ/ blk=
;; Received 604 bytes from 199.249.120.1#53(b2.org.afilias-nst.org) in 35 ms

_https._tcp.pkg.pfsense.org. 60 IN      SRV     10 10 443 files00.netgate.com.
_https._tcp.pkg.pfsense.org. 60 IN      SRV     10 10 443 files01.netgate.com.
pfsense.org.            300     IN      NS      ns2.netgate.com.
pfsense.org.            300     IN      NS      ns1.netgate.com.
;; Received 346 bytes from 162.208.119.38#53(ns2.netgate.com) in 101 ms

The DNS story is the usual :

The resolver ask to the "13 DNS gods" : who handles .org ?
It received a list with those who handle .org. k.root-servers.net was friendly enough to tell me this.
From one of these tld "org" DNS servers, it was b2.org.afilias-nst.org btw, I got the list of the two name servers for pfsense.org.
The were ns2.netgate.com. and ns1.netgate.com.
It was ns2 who gave me the answer about the SRV record :

files00.netgate.com.

Take note : this is not an A record, neither an AAAA, not a MX, neither a TXT. It's a SRV record - less known. Windows uses it also (for its updates etc).

Your path would be different - some one in your path won't answer. UP to you to figure out who.
I hope it local.
Because, if not, cloudflare doesn't want you to see or access "some of the Internet" ;)

Btw : cloudfare gets its info from : the 13 mentioned above.

wbptls

@gertjan so the router does not show up in the query log of pihole and the dig command you specified above results in no servers could be reached ,it seems the queries from pfsense have no path to go outside.i dont think the dns server(cloudflare) is to blame here as it is at the edge of the network.
it could be nat. my physical connection is isp-->pfsense-->old wifi router in apmode/switch--->gigabit switch-->pihole

Gertjan

Your PI-hole could be the local DNS for your network, but why looping pfSense through pi-hole also ?
Set this :

on the DHCP server settings page.
And just leave the DNS traffic from pfSense as it was.

Also, not related : these "old wifi router in apmode/switch" have often 100 Mbits/sec interfaces, limiting your (local) network speed.

wbptls

@gertjan i had dns in dhcp,anyways enabling the dns resolver(in dns resolver page) in the pfsense interface got pfsense working,thanks.

how do i set it to ping to cloudflare though than my isp's dns,do i put the cloudflare ip in the general setup dns box ? will putting it in the general setup dns box on general setup page also make my dhcp clients resolve to that(which i dont want). Thank you for the help.

"Also, not related : these "old wifi router in apmode/switch" have often 100 Mbits/sec interfaces, limiting your (local) network speed."
all my ethernet devices are on the gigabit switch.Buying a gigabit wifi router soon.

also can you please look at my other post link text i want to force my local lan traffic through a proxy server running on a vm on the same lan/subnet but nat does not seem to work.