Upgrade not possible from 2.5.0 to 2.5.2. Netgate DNS issue?
-
Hi,
there is no upgrade possible on my pfsense box.
The error is "Unable to check for updates" in the gui.
I have also read these two topics:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/upgrades.html#upgrade-troubleshooting-metadata
https://forum.netgate.com/topic/161413/problems-upgrading-check-the-troubleshooting-upgrades-documentation/1That's what I have tried.
1.)Switch and save the current branch in the gui.
=> no result
2.)
Upgrade form the consoleUpdating pfSense-core repository catalogue... pkg-static: https://packages.netgate.com/pfSense_v2_5_2_amd64-core/meta.txz: No address record ...
3.) Manual Upgrade
pfSense-upgrade -d -c >>> Updating repositories metadata... Updating pfSense-core repository catalogue... pkg-static: https://packages.netgate.com/pfSense_v2_5_2_amd64-core/meta.txz: No address record repository pfSense-core has no meta file, using default settings ..
4.) Manual Metadata Upgrade
pkg-static update -f Updating pfSense-core repository catalogue... pkg-static: https://packages.netgate.com/pfSense_v2_5_2_amd64-core/meta.txz: No address record repository pfSense-core has no meta file, using default settings
But the reason is always the same,. First I thought there is no a-record for packages, but in the documentation is stated that SRV recodes are used.
But there are no SRV records present as well!host -t srv _https._tcp.packages.netgate.com _https._tcp.packages.netgate.com has no SRV record
All my opther DNS queries are working.
Is there a temporary problem on the netgate DNS? -
It seems there is a problem in our local DNS, because with google it is working. Sorry for that!
dig @8.8.8.8 _https._tcp.packages.netgate.com SRV ; <<>> DiG 9.16.12 <<>> @8.8.8.8 _https._tcp.packages.netgate.com SRV ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33877 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;_https._tcp.packages.netgate.com. IN SRV ;; ANSWER SECTION: _https._tcp.packages.netgate.com. 44 IN SRV 10 10 443 files00.netgate.com. _https._tcp.packages.netgate.com. 44 IN SRV 10 10 443 files01.netgate.com. ;; Query time: 7 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Jul 22 14:42:36 CEST 2021 ;; MSG SIZE rcvd: 139
-
@sepp_huber said in Upgrade not possible from 2.5.0 to 2.5.2. Netgate DNS issue?:
because with google it is working
Google ?
Do we need Google to update a device ? ;)
(that's scarry)
De pfSense default DNS settings, the way you found it when pfSense started the first time, works great :Enter an option: 13 >>> Updating repositories metadata... Updating pfSense-core repository catalogue... Fetching meta.conf: . done Fetching packagesite.txz: . done Processing entries: . done pfSense-core repository update completed. 7 packages processed. Updating pfSense repository catalogue... Fetching meta.conf: . done Fetching packagesite.txz: .......... done Processing entries: .......... done pfSense repository update completed. 502 packages processed. All repositories are up to date. Your packages are up to date pfSense - Netgate Device ID: b87955574de942xxxxx ....
-
The reason for the error was: DNS recursion was not allowed from the firewalls WAN address, only for our public DMZ addresses for the firewall.
WAN (wan) -> lagg2 -> v4: 62.XXX.YYY.ZZZ/29
OPTDMZ (opt1) -> lagg1 -> v4: 194.XXX.YYY.ZZZ/32The DNS location is in OPTDMZ 194.XXX.YYY.ZZZ/32
There must be a change, that pfsense is now using the WAN interface for the DNS query and not as expected the OPTDMZ Interface, where the DNS is located.
Any ideas?
-
Ok, that's not what i would call a default setup.
Which means : there's only one person who knows how your network knows : you.@sepp_huber said in Upgrade not possible from 2.5.0 to 2.5.2. Netgate DNS issue?
The DNS location is in OPTDMZ 194.XXX.YYY.ZZZ/32
Like : have the local pfSense resolver forward it's request to an upstream (and downstream, external DNS server).
Forward to 194.XXX.YYY.ZZZ/32 ?Or : again : the defaut DNS settings should work, as your WAN interface is (should be) the default gateway.
-
@gertjan said in Upgrade not possible from 2.5.0 to 2.5.2. Netgate DNS issue?:
Ok, that's not what i would call a default setup.
I know ;-)
Which means : there's only one person who knows how your network knows : you.
Yeah ;-)
@sepp_huber said in Upgrade not possible from 2.5.0 to 2.5.2. Netgate DNS issue?
The DNS location is in OPTDMZ 194.XXX.YYY.ZZZ/32
Like : have the local pfSense resolver forward it's request to an upstream (and downstream, external DNS server).
Forward to 194.XXX.YYY.ZZZ/32 ?Or : again : the defaut DNS settings should work, as your WAN interface is (should be) the default gateway.
If you mean the DNS Forwarder or the DNS Resolver, we are not using it.
The remote DNS servers are configured via "General Setup-> DNS Server settings" and are listed in /etc/resolv.conf.There was no config change on the firewall or on the DNS, I am just wondering why pfsense is NOT using the OPTDMZ address for the DNS queries. In the past it has used it...
In my opinion there is no routing and the default Gateway is not used if the DNS-Server is located in an network which is directly attached to the firewall, in my case OPTDMZ.
-
@sepp_huber said in Upgrade not possible from 2.5.0 to 2.5.2. Netgate DNS issue?:
If you mean the DNS Forwarder or the DNS Resolver, we are not using it.
The remote DNS servers are configured via "General Setup-> DNS Server settings" and are listed in /etc/resolv.conf.So you have something like
nameserver 194.XXX.YYY.ZZZ
in this file.
When you use the console and dig something like
dig google.com
it works ?
Or
dig @194.XXX.YYY.ZZZ google.com
@sepp_huber said in Upgrade not possible from 2.5.0 to 2.5.2. Netgate DNS issue?:
In my opinion there is no routing and the default Gateway is not used if the DNS-Server is located in an network which is directly attached to the firewall, in my case OPTDMZ.
There must be some info in the routing table that mentions :
194.XXX.YYY.ZZZ is on 'this' (OPTDMZ) interface.
All the other addresses are reachable on the 'other' (WAN) interface. -
I think we are talking past each other on the base of my poor explanations ;-)
I could solve the problem already ... but I cannot understand it:
The main problem was that the remote DNS servers have denied dns recursion queries from the pfsense WAN interface. The recursion queries where already allowed for the pfsense OPTDMZ interface.
The solution was to allow the recursion from the pfsense WAN interface.
So my question was, why this was suddenly necessary without config change. Before all dns queries are coming from the OPTDMZ interface.dig @194.XXX.YYY.ZZZ google.com
=> no recursion allowed, because SOURCE IP is pfsense WAN
=> Before SOURCE IP for DNS queries was 194.XXX.YYY.1 (OPTDMZ pfsense)There
@gertjan said in [Upgrade not possible from 2.5.0 to 2.5.2. Netgate
So you have something like
nameserver 194.XXX.YYY.ZZZ
yes
There must be some info in the routing table that mentions :
194.XXX.YYY.ZZZ is on 'this' (OPTDMZ) interface.
All the other addresses are reachable on the 'other' (WAN) interface.
In the route table
Again, in my opinion there is no routing and the default Gateway is not used if the DNS-Server is located in an internal network which is directly attached to the firewall, in my case OPTDMZ.In the route table there is an entry that all traffic goes to a device ...
Destination Gateway Flags Netif 194.XXX.YYY.0/24 link#11 U lagg1
I think we are fine ;-)