Unable to upgrade Netgate 1100 from pfSense+ 24.11 to 25.07.1 / 25.11.x – repository metadata fetch fails with HTTP 400

e4ch

I have a Netgate 1100 device, just over one year old, with pfSense+ running firmware 24.11. Firmware upgrade through the UI is not possible, but I do have SSH access.

System information:

Platform: Netgate 1100
Architecture: arm64
Current kernel:
FreeBSD 15.0-CURRENT #0 plus-RELENG_24_11-n256407-1bbb3194162
freebsd-version -kru reports:
15.0-CURRENT
15.0-CURRENT
15.0-CURRENT

I am attempting to upgrade to a newer pfSense+ release. The update UI presents the available trains, including 25.07.1 and a newer 25.11.x train. Selecting the newer train does not allow the upgrade to proceed successfully.

Earlier in troubleshooting, repeated update checks from both the GUI and CLI caused overlapping pfSense-upgrade and pkg-static processes, occasionally resulting in "another instance is running" messages. After a reboot the system became stable again. There are currently no lingering pfSense-upgrade or pkg-static processes and no upgrade lock files remain.

Current repository configuration:

pfSense-core:
https://pfsense-plus-pkg.netgate.com/pfSense_plus-v25_07_1_aarch64-core

pfSense:
https://pfsense-plus-pkg.netgate.com/pfSense_plus-v25_07_1_aarch64-pfSense_plus_v25_07_1

pkg-static -vv confirms those repositories are active.

pfSense-upgrade -c output:

Messages:
Your Netgate device has pfSense+ as part of your device purchase.
ERROR: It was not possible to determine pkg remote version

> > > Updating repositories metadata...failed.
> > > ERROR: It was not possible to determine pfSense remote version
> > > 25.07.1 version of pfSense is available

pfSense-upgrade -d and pkg-static update -f both fail while updating repository metadata.

The most significant finding is from:

pkg-static -d update -f

The device successfully:

Resolves the Netgate package server SRV targets.
Connects to the package servers.
Completes TLS 1.3 negotiation.
Successfully validates the Netgate certificate.

However, every repository metadata request receives:

HTTP/1.1 400 Bad Request

Examples:

GET /pfSense_plus-v25_07_1_aarch64-core/meta.conf
GET /pfSense_plus-v25_07_1_aarch64-core/meta.txz
GET /pfSense_plus-v25_07_1_aarch64-pfSense_plus_v25_07_1/packagesite.tzst

The repository update then fails with:

"Unable to update repository pfSense-core"
"Unable to update repository pfSense"
"Error updating repositories"

Network topology:

The LAN interface is connected to the internal LAN.
The WAN interface is connected to a separate network that has no Internet access.
The management LAN itself is behind another firewall.
Outbound HTTP and HTTPS traffic are permitted.
DNS resolution works normally.
TLS connections to the Netgate package servers succeed.

Could you please advise:

Whether the device entitlement, registration, or repository authorization status appears correct on your side.
Whether there are known issues upgrading a Netgate 1100 from pfSense+ 24.11 to 25.07.1 or 25.11.x.
Whether any repository-side issue could cause valid package metadata requests to return HTTP 400.
Whether any additional ports, destinations, or update infrastructure endpoints must be reachable beyond standard HTTPS.

Attached the complete debug output from pkg-static -d update -f
pkg-static_update_output.txt

e4ch

UPDATE:
I did some further troubleshooting. I had some (limited) success with updating the pfSense package:
pkg-static install -fy pfSense-repo
This actually worked and upgraded the package from 1.21.3_4 to 1.21.3_5 successfully.
Unfortunately, that broke the package:
ld-elf.so.1: Shared object "libmd.so.7" not found, required by "pkg"
I couldn't fix that, so I ended up with nuking everything by reimaging the device through the serial console. That worked (some packages are still reinstalling in the background as usual, which may take a few hours), but I'm now on version 26.03.1, which should be the latest version.
One thing I noticed: When reimaging through the serial console, the device needs internet connection (as described). I did connect it on the WAN port to my local LAN, which should provide DHCP and Internet access, the serial installer told me it couldn't reach the Netgate servers there as well. I ended up with plugging it into the the unprotected raw internet (no NAT, no firewall, direct internet). During installation this is probably no big deal, although there are always opportunistic attacks ongoing. After installation finished I removed the cable again and completed the rest locally.
But this leaves me wondering: What kind of internet access is needed there? Obviously standard https access is not enough?
Also in the UI: The dashboard shows in the upper right corner "Netgate Services And Support" and keeps spinning forever with the "Retrieving support information".
So my device is fixed, but I would still like to know what kind of internet access is required.

UPDATE2:

And now I see under the alarms:
General

The GUI HTTPS certificate has been renewed or replaced with a secure default. @ 2026-06-02 00:51:17
Package reinstall process was ABORTED due to lack of internet connectivity @ 2026-06-02 01:32:37

Upgrade

check_upgrade: "Updating repositories metadata" returned error code 1 @ 2026-06-02 01:10:36

How can I fix this "connectivity" issue? (It does have internet access on the LAN), but it seems that pfSense+ needs something more.

Gertjan

@e4ch said in Unable to upgrade Netgate 1100 from pfSense+ 24.11 to 25.07.1 / 25.11.x – repository metadata fetch fails with HTTP 400:

But this leaves me wondering: What kind of internet access is needed there? Obviously standard https access is not enough?
Also in the UI: The dashboard shows in the upper right corner "Netgate Services And Support" and keeps spinning forever with the "Retrieving support information".
So my device is fixed, but I would still like to know what kind of internet access is required.

The same access or connection as any other 'connected' device, as your phone, pad, PC, portable PC, light bulb TV, etc etc.
A "Netgate 1100" uses a wired connection, so no 'Wifi', it uses a RJ45 cable that you connect to the WAN on the pfSense side and the LAN on the ISP side (a upstream router, modem, ISP device whatever).
Seems silly, but that's it.
Ones connected, as on any other device, you can check :

My WAN IPv4 is 192.168.10.4 - my upstream ISP router uses 191.168.10.1 - so that's the pfSense gateway, and I use the DHCP method of connecting as this is the most common way.
Be aware : your ISP can use another method. Like pppoe, or a staticic IPv4 setup, or something else.

stephenw10

@e4ch said in Unable to upgrade Netgate 1100 from pfSense+ 24.11 to 25.07.1 / 25.11.x – repository metadata fetch fails with HTTP 400:

However, every repository metadata request receives:

HTTP/1.1 400 Bad Request

That indicates the client cert is invalid for some reason, probably out of date.

If you're testing at the command line then first update it using: pfSense-repoc -N

That gets run when you connect to the gui so if it's failing there it may return an error. If so try pfSense-repoc -ND to get more diag output.

e4ch

@Gertjan said in Unable to upgrade Netgate 1100 from pfSense+ 24.11 to 25.07.1 / 25.11.x – repository metadata fetch fails with HTTP 400:

red connection, so no 'Wifi', it uses a RJ45 c

Thanks. Fyi, only LAN connects (via another firewall) to the Internet, but the connection is up and working. LAN Interface shows "up" and with Diagnostics I get connections. LAN is static, not DHCP like in your screenshot. Other than that, I don't see anything unusual. On the Status / Interfaces page, below the various interfaces, it shows the warning that dial-up reconnects whenever any package comes. I'm not aware of having configured dial-up anywhere, so I assume that warning always appears.

e4ch

@stephenw10 Thanks. Too late to try this now. But I did check the certificate and did a certctl rehash, without success. Not sure what a client certificate would be used for if it's just updating firmware.

Worth mentioning though that the problem persists even with the latest firmware installed:

stephenw10

So pfSense-repoc -N completes without error? certctl won't affect that.

If you send me your NDI in chat I can check what our servers are seeing/responding.

e4ch

@stephenw10 said in Unable to upgrade Netgate 1100 from pfSense+ 24.11 to 25.07.1 / 25.11.x – repository metadata fetch fails with HTTP 400:

So pfSense-repoc -N completes without error? certctl won't affect that.

If you send me your NDI in chat I can check what our servers are seeing/responding.

Thanks. The pfSense-repoc -N does not fail. It just prints "Messages:" and "Your Netgate device has pfSense+ as part of your device purchase.", nothing else. I'll try to DM you my device ID.

When I run "pfSense-upgrade -c" now (not sure what that does exactly), the output is much shorter, because everything is up to date, but I still get an error message:
Messages:
Your Netgate device has pfSense+ as part of your device purchase.
>>> Updating repositories metadata...failed.
Your system is up to date

I highly suspect some limitation on the outgoing big firewall, because when I did the serial re-imaging, this process also requires an internet connection. With the cable connected to the LAN port it didn't work. I expected that maybe in this serial re-image process, it might expect Internet connection only on the WAN port, so I connected the LAN cable there instead, but it also said "cannot reach Netgate servers". As this device was in boot-up serial mode, I don't think there was much danger exposing it to the raw internet, so I took a long cable and connected that from the raw internet to the WAN port. Only then the serial installation worked. This means that some filter on the outgoing firewall in my LAN where this Netgate 1100 is connected must be filtering the Netgate-server connections. But TCP/443 is completely open (except for some known malware IPs), so it can't be that. DNS is closed, but I have internal DNS servers that do work fine.

I've also tried logging on the upstream firewall and couldn't see much blocked traffic, at least nothing that I can associate with firmware updates (I cannot see source IP due to NAT), but I saw some blocked UDP/443 packets at the time of firmware update checks. That would not be https traffic though. Destination servers were 104.16.5.65, 104.16.186.41, 34.117.59.81, 142.251.150.119. These belong to Cloudflare, so probably not Netgate.

If you have a current list of all Netgate update servers, I'm happy to create an upstream firewall exception rule (at least for logging) and see if there are any blockings.

UPDATE:
pfSense-upgrade -d -c returns:
Messages:
Your Netgate device has pfSense+ as part of your device purchase.
>>> Updating repositories metadata...
Updating pfSense-core repository catalogue...
pkg-static: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_1_aarch64-core/meta.conf: Timeout was reached
pkg-static: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_1_aarch64-core/meta.txz: Timeout was reached
repository pfSense-core has no meta file, using default settings
pkg-static: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_1_aarch64-core/data.pkg: Timeout was reached
pkg-static: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_1_aarch64-core/data.tzst: Timeout was reached
pkg-static: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_1_aarch64-core/packagesite.pkg: Timeout was reached
pkg-static: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_1_aarch64-core/packagesite.tzst: Timeout was reached
Unable to update repository pfSense-core
Updating pfSense repository catalogue...
pkg-static: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_1_aarch64-pfSense_plus_v26_03_1/meta.conf: Timeout was reached
pkg-static: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_1_aarch64-pfSense_plus_v26_03_1/meta.txz: Timeout was reached
repository pfSense has no meta file, using default settings
pkg-static: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_1_aarch64-pfSense_plus_v26_03_1/data.pkg: Timeout was reached
pkg-static: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_1_aarch64-pfSense_plus_v26_03_1/data.tzst: Timeout was reached
pkg-static: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_1_aarch64-pfSense_plus_v26_03_1/packagesite.pkg: Timeout was reached
pkg-static: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_1_aarch64-pfSense_plus_v26_03_1/packagesite.tzst: Timeout was reached
Unable to update repository pfSense
Error updating repositories!
Your system is up to date

e4ch

Problem resolved.

The original problem was that I couldn't upgrade. After breaking the installation, I did a full reinstall through serial console after boot with the USB stick. That also required an internet connection through a cable and didn't work with the LAN connection. After the install and restoring a backup of the config, everything was on the newest firmware, but still all sluggish (which I assumed was the low-powered device) and pfSense-upgrade still with many timeout errors and the support information on the dashboard not loading, so pretty much the same error as before, just that there was no update.

Maybe as a background of the config: The LAN-connection has internet access, the other side goes to an isolated network with no internet. The LAN has internet connection, goes over a router with NAT and then to a bigger pfSense firewall. The router has also the firewall enabled, but is not really doing much filtering, the main firewall rules are on the pfSense. There, I don't see the source, because the router is doing NAT, so all the upstream pfSense sees is coming from the router. I've found out the two pfSense IP addresses from the pkg-static -d update -f command, which runs without errors now. I've added those two IP addresses to the upstream pfSense to monitor traffic and allow all outgoing, but nothing new there, just TCP-S entries for port 443. I've also added some logging onto the router and exceptions for the pfSense in question, as there I do have the source IPs. Then I saw a lot of requests to local ISP servers, NTP, and DNS root servers. This is not supposed to happen, because outgoing DNS is completely blocked and should go through my own DNS servers. Therefore I assumed something with DNS is not correct, even though the device could do DNS resolution.

The System/General Setup has the correct local DNS servers listed. The DNS Server Override option is not enabled and the Resolution Behavior is "use local DNS (127.0.0.1), fall back to remote DNS (Default)". So the DNS configuration actually looks good. The actual problem was that DNS Resolver was enabled. That might be the default, but that's a problem, because that checks for the root DNS and all that. After disabling this service, everything works fine now. So it seems that this service was trying to resolve all DNS and was constantly failing, because DNS ports upstream are blocked. Not sure why this is causing so much trouble, especially as the normal configured DNS are fully working.

Anyway, since this service is disabled, now I'm no longer getting any timeouts anywhere, the UI login doesn't take 30 seconds anymore, the dashboard quickly shows the Version information with all updates, the System/Update doesn't take minutes to load and the dashboard area with "Netgate Services and Support" now also shows up (previously loading forever). With that last thing working, I also found out that I do have "pfSense TAC Lite" support and not only community forums, lol.

Well, finally all resolved years after buying the device. All good now. Thanks a lot to @stephenw10 who also helped.

Gertjan

@e4ch said in Unable to upgrade Netgate 1100 from pfSense+ 24.11 to 25.07.1 / 25.11.x – repository metadata fetch fails with HTTP 400:

The System/General Setup has the correct local DNS servers listed. The DNS Server Override option is not enabled and the Resolution Behavior is "use local DNS (127.0.0.1), fall back to remote DNS (Default)". So the DNS configuration actually looks good. The actual problem was that DNS Resolver was enabled. That might be the default, but that's a problem, because that checks for the root DNS and all that. After disabling this service, everything works fine now. So it seems that this service was trying to resolve all DNS and was constantly failing, because DNS ports upstream are blocked. Not sure why this is causing so much trouble, especially as the normal configured DNS are fully working.

So the the (this) pfSense had no WAN Internet access - Internet was available on it's LAN.
This will break DNS - or at least unbound, the resolver. Was it ever informed of this information, which is highly .... non-standard ?

A resolver looking for root, then TLD servers and then domain name servers, that's how things are done since DNS was invented.
Heck, 1.1.1.1 8.8.8.8 and friends are doing just that, as they are resolvers after all.

Anyway, glad everything is humming again for you.

e4ch

@Gertjan No, it doesn't break DNS if only LAN is connected. Actually, unbound doesn't really care which interface you use. And the configuration page allows to select the interfaces to use and the default is "All", so the DNS Resolver would have still worked, if the DNS traffic would not have been blocked when not going to the LAN-DNS. The only strange thing is that having the local DNS resolver non-working also blocks the entire DNS lookup and the normal DNS lookup will only be done after the resolver has failed. I would have expected that the regular DNS is being used and the resolver only if the local one doesn't have data, but I'm not a DNS expert.