Upgrade not possible from 2.5.0 to 2.5.2. Netgate DNS issue?

sepp_huber

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/1

That's what I have tried.
1.)Switch and save the current branch in the gui.
=> no result
2.)
Upgrade form the console

Updating 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?

sepp_huber

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

Gertjan

@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
....

sepp_huber

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/32

The 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?

Gertjan

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.

sepp_huber

@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.

Gertjan

@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.

sepp_huber

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 ;-)