no packages in package manager
-
no packages in package manager..
ISP issue or anything else?
it is getting harder every day to connect to external internet...
there must be an option for manual package installation/update
-
@dealornodeal said in no packages in package manager:
no packages in package manager..
Using pfSense default settings ?
This issue is often seen when DNS settings are 'changed' (the default ones will work).
What does the Status > System Logs > System > DNS Resolver log tell you ?
Or, FreeBSD (pfSense) thinks it can use IPv6 - or it's unusable / not set up correctly.You tell us what wrong, and we'll tell you what's up ^^
edit : pfsense manual package problems check any of them.
-
This post is deleted! -
Hello, no defaults, I try to avoid using IPv6
System logs report blocked telemetry, thats it
Jan 17 21:53:38 filterdns Adding Action: pf table: mstelemetry host: rad.live.com
Jan 17 21:53:38 filterdns Adding Action: pf table: mstelemetry host: rad.msn.com
Jan 17 21:53:38 filterdns Adding Action: pf table: mstelemetry host: redir.metaservices.microsoft.com
Jan 17 21:53:38 filterdns Adding Action: pf table: mstelemetry host: reports.wes.df.telemetry.microsoft.com
Jan 17 21:53:38 filterdns Adding Action: pf table: mstelemetry host: schemas.microsoft.akadns.net
Jan 17 21:53:38 filterdns Adding Action: pf table: mstelemetry host: secure.adnxs.com -
All these domains have probably more then one A record.
These domains expose functions to the public that should be reachable all over the planet "what ever happens", for the entire planet.
Or, the alias uses the domain to get one (1) A. NOT all the A records.
The next time it refreshed, another A might get inserted. (and the firewall is reloaded because an alias changed).To make a long story short : you can't use the alias functionality to create a matching rules that finds 'facebook.com' or 'youtube.com' : it won't work.
Aliases works fine for one to one relation between a domain and an IP address.If you want to filter for example, "rad.live.com", use pfBlockerNG-devel.
You have only "filterdns" lines in the DNS log ? No unbound logs ?
-
outbound:
Jan 17 22:45:59 unbound 33941:0 info: server stats for thread 0: 19 queries, 13 answers from cache, 6 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Jan 17 22:45:59 unbound 33941:0 info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
Jan 17 22:45:59 unbound 33941:0 info: average recursion processing time 0.063351 sec
Jan 17 22:45:59 unbound 33941:0 info: histogram of recursion processing times
Jan 17 22:45:59 unbound 33941:0 info: [25%]=0.036864 median[50%]=0.049152 [75%]=0.06144
Jan 17 22:45:59 unbound 33941:0 info: lower(secs) upper(secs) recursions
Jan 17 22:45:59 unbound 33941:0 info: 0.000512 0.001024 1
Jan 17 22:45:59 unbound 33941:0 info: 0.032768 0.065536 4
Jan 17 22:45:59 unbound 33941:0 info: 0.131072 0.262144 1
Jan 17 22:45:59 unbound 33941:0 info: server stats for thread 1: 43 queries, 13 answers from cache, 30 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Jan 17 22:45:59 unbound 33941:0 info: server stats for thread 1: requestlist max 8 avg 2.7 exceeded 0 jostled 0can't paste all lines due to site spam filter limitations (flagged as spam), btw my NTP server probably not working properly as well, wrong time and date
-
Jan 17 22:45:59 unbound 33941:0 info: 0.032768 0.065536 3
Jan 17 22:45:59 unbound 33941:0 info: 0.065536 0.131072 4
Jan 17 22:45:59 unbound 33941:0 info: server stats for thread 3: 61 queries, 35 answers from cache, 26 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Jan 17 22:45:59 unbound 33941:0 info: server stats for thread 3: requestlist max 1 avg 0.0769231 exceeded 0 jostled 0
Jan 17 22:45:59 unbound 33941:0 info: average recursion processing time 0.073920 sec
Jan 17 22:45:59 unbound 33941:0 info: histogram of recursion processing times
Jan 17 22:45:59 unbound 33941:0 info: [25%]=0.0365489 median[50%]=0.0529329 [75%]=0.090112
Jan 17 22:45:59 unbound 33941:0 info: lower(secs) upper(secs) recursions
Jan 17 22:45:59 unbound 33941:0 info: 0.008192 0.016384 4
Jan 17 22:45:59 unbound 33941:0 info: 0.016384 0.032768 1
Jan 17 22:45:59 unbound 33941:0 info: 0.032768 0.065536 13
Jan 17 22:45:59 unbound 33941:0 info: 0.065536 0.131072 4
Jan 17 22:45:59 unbound 33941:0 info: 0.131072 0.262144 3
Jan 17 22:45:59 unbound 33941:0 info: 0.262144 0.524288 1
Jan 17 22:46:05 unbound 20880:0 notice: init module 0: validator
Jan 17 22:46:05 unbound 20880:0 notice: init module 1: iterator
Jan 17 22:46:05 unbound 20880:0 info: start of service (unbound 1.10.1).
Jan 17 22:46:05 unbound 20880:0 info: generate keytag query _ta-4a5c-4f66. NULL IN
Jan 17 22:46:05 unbound 20880:0 info: failed to prime trust anchor -- DNSKEY rrset is not secure . DNSKEY IN -
Impressive.
The last time your unbound restarted was some 6 months ago.
Just to be sure : goto Status > Services and restart unbound.@dealornodeal said in no packages in package manager:
spam filter limitations
That's why pastebin.com was created ;)
@dealornodeal said in no packages in package manager:
my NTP server probably not working properly as well, wrong time and date
Ah .... that's another problem. Systems using the wrong time is a nice starting point for very random, strange errors.
-
DNS:
https://pastebin.com/Wss2SAazmight be also interesting with some sort of knowledge
General:
https://pastebin.com/CRn1dHBAGateways:
Jan 14 03:53:20 dpinger WAN_DHCP 10.125.190.113: sendto error: 65
Jan 14 03:53:21 dpinger WAN_DHCP 10.125.190.113: sendto error: 65
Jan 14 03:53:21 dpinger WAN_DHCP 10.125.190.113: sendto error: 65
Jan 14 03:53:23 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 10.125.190.113 bind_addr 10.125.190.113 identifier "WAN_DHCP "
Jan 14 05:33:22 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 10.125.190.113 bind_addr 10.125.190.113 identifier "WAN_DHCP "
Jan 14 07:16:42 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 10.125.190.113 bind_addr 10.125.190.113 identifier "WAN_DHCP " -
Your Gateway log lines :
You can check the led on your WAN NIC : it's probably not lit any more, as the link is down : the device on the other side "pulled the plug" ....
That's when dpinger starts to spit out "sendto error: 65" messages.Two seconds later, some IP address is assigned to the WAN (by the DHCP client on WAN) = 10.125.190.113 which work out.
If your WAN interface has 10.125.190.113 then the "dest_addr" couldn't be 10.125.190.113 - it should be something else = the gateway.For me this means you should - as stated above - inform the DHCP client to wait 10 or 20 seconds, after the WAN comes up.
Now, the modem (is it a modem ?) wakes up it's LAN side interface, but is not ready at all to handle = transfer DHCP requests to the ISP because de modem uplink isn't established yet.Anyway : first : set the time manually. And check if the local clock actually works by shutting down the device a minute or so. When rebooted pfSense, the time should still be somewhat ok.
Only then the NTP process will do the fine calibration.Your General log is telling you all over the place to use the correct time.
-
you are right, actually WAN GW is 10.125.190.254
as per your advice I changed settings to no interface (wildcard) and relaunched NTP service and everything works fine now, even package manager. All packages are in the place available for downloading.
Thank you
