Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Package repo connection issues on fresh bare metal install

    Scheduled Pinned Locked Moved Problems Installing or Upgrading pfSense Software
    18 Posts 3 Posters 595 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • hiflyr777H
      hiflyr777
      last edited by

      I'm hitting a wall connecting to the pfSense package repositories on a fresh, bare-metal pfSense install. Everything worked perfectly when I was running pfSense as a Proxmox VM, but now that I’ve moved to bare metal, pkg-static can’t reach the repos and I can’t install additional drivers or packages (like I need to for a Realtek 8125 2.5Gb card).

      I restored my old config.xml after installing pfSense on the physical hardware (and modifying the interfaces to match the current ones).

      The system otherwise has basic connectivity—LAN clients can reach the Internet, DNS resolution works, HTTPS is fine for most external sites, etc. But whenever I try to run pkg-static install or pkg-static update, it times out attempting to reach Netgate’s servers (pkg00-atx.netgate.com, pkg01-atx.netgate.com).

      My Setup & Goal
      • pfSense 2.7.2-RELEASE (bare metal)
      • I need to install the Realtek 8125 driver package for my motherboard’s 2.5GbE NIC, but the package manager is currently unreachable.
      • For now, I’m using the motherboard’s Ethernet port, which works, but I can’t proceed with package installations.

      What Works
      • General Internet connectivity from LAN clients
      • DNS resolution (both pfSense system DNS and external like 8.8.8.8)
      • HTTPS to other sites (e.g., https://www.google.com)
      • SRV record resolution for _pkg._tcp.pkg.pfsense.org
      • Traceroute to Netgate’s network (stops at yul-zco10.netgate.com/208.123.73.4)

      What Doesn’t Work
      • pkg-static install -f pkg (fails with connection error)
      • Direct HTTPS connections to pkg00-atx.netgate.com:443 and pkg01-atx.netgate.com:443 time out
      • Connection attempts to 208.123.73.207:443 and 208.123.73.209:443 time out

      Verification & Troubleshooting Done So Far
      1. SSL Certificates:
      • Confirmed the presence of /etc/ssl/cert.pem and ca-root-nss.crt.
      • Checked the trusted keys in /usr/local/share/pfSense/keys/pkg/trusted/.
      2. Repository Config:
      • Examined /usr/local/etc/pkg/repos/pfSense.conf for correct repo URL (the default pkg+https://pkg.pfsense.org/pfSense_v2_7_2_amd64-core with mirror_type: "srv").
      • Also tried manually specifying pkg00-atx.netgate.com and pkg01-atx.netgate.com, but got timeouts.
      3. Forcing IPv4:
      • Used the -4 flag on fetch and pkg commands—still no luck.
      4. Connectivity & DNS Checks:
      • Can ping/traceroute Netgate servers, see them respond to ICMP.
      • Outbound HTTPS to Google and other sites works fine.
      5. No Floating Rules, No IDS/IPS:
      • I do not run Snort or Suricata. No custom floating rules.
      6. Reset States & Certificates:
      • Cleared the state table, re-hashed certificates, still stuck.
      7. Partial Handshake Observed in Packet Capture:
      • pfSense sends a SYN; the Netgate server replies with SYN,ACK multiple times; pfSense never sends the final ACK, leading to timeouts.

      pfSense is timing out when attempting to establish the TLS connection with the repo servers. It’s almost like the inbound SYN,ACK is never fully processed by pfSense’s firewall, even though I can see it arrive in a packet capture on WAN.

      I have no multi-WAN, no custom NAT (using automatic), no services like Captive Portal or Proxy and Hardware offloading is disabled (checksum, TSO, LRO all off).

      I would truly appreciate any guidance or suggestions!

      stephenw10S GertjanG 2 Replies Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        Run: pkg -d update

        What error is shown?

        hiflyr777H 1 Reply Last reply Reply Quote 0
        • hiflyr777H
          hiflyr777 @stephenw10
          last edited by

          @stephenw10 Here's what I get:

          
          DBG(1)[464181] CURL: attempting to fetch from , left retry 2
          
          * Couldn't find host pkg01-atx.netgate.com in the .netrc file; using defaults
          * Hostname pkg01-atx.netgate.com was found in DNS cache
          * Trying 208.123.73.209:443...
          * Connect to 208.123.73.209 port 443 failed: Operation timed out
          * Trying [2610:160:11:18::209]:443...
          * Immediate connect fail for 2610:160:11:18::209: No route to host
          * Failed to connect to pkg01-atx.netgate.com port 443 after 31 ms: Couldn't connect to server
          * Closing connection
          
          DBG(1)[464181] CURL: attempting to fetch from , left retry 1
          
          * Couldn't find host pkg0-atx.netgate.com in the .netrc file; using defaults
          * Hostname pkg0-atx.netgate.com was found in DNS cache
          * Trying 208.123.73.207:443...
          * Connect to 208.123.73.207 port 443 failed: Operation timed out
          * Trying [2610:160:11:18::207]:443...
          * Immediate connect fail for 2610:160:11:18::207: No route to host
          * Failed to connect to pkg0-atx.netgate.com port 443 after 31 ms: Couldn't connect to server
          * Closing connection
          
          pkg: An error occurred while fetching package
          Unable to update repository pfSense
          Error updating repositories!
          
          [2.7.2-RELEASE][root@pfSense.home.arpa]/root:
          
          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Hmm, what happens if you try Diag > Test Port to either of those IPs on port 443?

            That is working fine for me here from 2.7.2. It just runs a TCP handshake test.

            Check the routing table for some rogue route.

            hiflyr777H 1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              What NIC are you using currently if you don't yet have the 2.5G re driver?

              hiflyr777H 1 Reply Last reply Reply Quote 0
              • hiflyr777H
                hiflyr777 @stephenw10
                last edited by

                @stephenw10 I have an i225 which just works

                1 Reply Last reply Reply Quote 0
                • hiflyr777H
                  hiflyr777 @stephenw10
                  last edited by hiflyr777

                  @stephenw10 See screenshot below for the Test Port.
                  Would you like a shot of the routing table?

                  Screenshot 2025-02-04 at 4.49.32 PM.png

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    Can you ping those IP addresses? If so does the latency look correct from where you are?

                    Try running: pfSense-repoc or pfSense-repoc -D

                    That connects to ews.netgate.com in the same subnet.

                    hiflyr777H 1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator @hiflyr777
                      last edited by

                      @hiflyr777 said in Package repo connection issues on fresh bare metal install:

                      • Traceroute to Netgate’s network (stops at yul-zco10.netgate.com/208.123.73.4)

                      That's odd. The hostname there looks like it went through OCR! It should be fw1-zcolo.netgate.com.

                      udp traceroute from pfSense will indeed stop there but icmp should complete: traceroute -I 208.123.73.207

                      hiflyr777H 1 Reply Last reply Reply Quote 0
                      • hiflyr777H
                        hiflyr777 @stephenw10
                        last edited by

                        @stephenw10 I can ping them and the latency seems reasonable:

                        PING 208.123.73.207 (208.123.73.207): 56 data bytes
                        64 bytes from 208.123.73.207: icmp_seq=0 ttl=55 time=68.132 ms
                        64 bytes from 208.123.73.207: icmp_seq=1 ttl=55 time=66.051 ms
                        64 bytes from 208.123.73.207: icmp_seq=2 ttl=55 time=68.424 ms
                        
                        [2.7.2-RELEASE][root@pfSense.home.arpa]/root: pfSense-repoc
                        Repo: failed to fetch the repo data
                        Failed to read the repo data.
                        
                        [2.7.2-RELEASE][root@pfSense.home.arpa]/root: pfSense-repoc -D
                        OS Version: 14.0-CURRENT
                        Platform: amd64
                        Product: pfSense
                        Version: 2.7.2-RELEASE
                        FS type: ufs
                        Language: en_US
                        Model: unknown hardware
                        Serial: (null)
                        Package prefix: pfSense-pkg-
                        
                        Repo Path: /usr/local/etc/pkg/pfSense.conf
                        Request query:
                        {
                          "platform": "unknown hardware",
                          "os": "FreeBSD",
                          "osver": "14.0-CURRENT",
                          "prod": "pfSense",
                          "ver": "2.7.2-RELEASE",
                          "ed": "Community"
                        }
                        
                        Error: Failed to fetch the repo data.
                        Failed to read the repo data.
                        
                        1 Reply Last reply Reply Quote 0
                        • hiflyr777H
                          hiflyr777 @stephenw10
                          last edited by

                          @stephenw10 Here's that traceroute...and we are getting to to fw1-colo.netgate.com at the end. I had to continually shorten this and replace with IP addresses to get the Akismet filter to take it:

                          traceroute to 208.123.73.207 (208.123.73.207), 64 hops max, 48 byte packets
                          1  pfsense (10.0.0.1)        2.449 ms  0.536 ms  0.481 ms
                          2  70.66.224.1 (70.66.224.1) 11.087 ms  9.999 ms  8.801 ms
                          3  [IP: 64.59.161.241]       9.119 ms  8.776 ms  11.133 ms
                          4  [IP: 24.244.63.78]        9.895 ms  10.483 ms  10.242 ms
                          5  [IP: 24.244.61.109]       9.486 ms  10.343 ms  9.693 ms
                          6  [IP: 66.163.72.22]        10.116 ms 10.752 ms 9.832 ms
                          ...
                          24 [IP: 208.123.73.4]        66.795 ms 68.634 ms 68.327 ms
                          25 208.123.73.207 (208.123.73.207) 67.524 ms 67.925 ms 66.364 ms```
                          
                          Thanks
                          1 Reply Last reply Reply Quote 1
                          • GertjanG
                            Gertjan @hiflyr777
                            last edited by

                            @hiflyr777 said in Package repo connection issues on fresh bare metal install:

                            Direct HTTPS connections to pkg00-atx.netgate.com:443 and pkg01-atx.netgate.com:443 time out

                            For what it's worth : when I copy these two in my browser :

                            ff9cf531-7727-4427-9c79-dd92b53ebe24-image.png

                            As you've installed very recently, what about : console option 4 : reset to default.
                            When it reboots, on the console, assign the minimum default settings for WAN and LAN.
                            You are allowed to chose a password. You are not allowed to change or modify or even look at DNS settings.
                            When done, you should have working setup, as the default Netgate Initial setup always works. If the issue is still there, the problem isn't pfSense.

                            Upgrade update packages etc (don't forget to install the system patches package and apply what is needed - like "all of them"!!).

                            Now, import your config, re assign interfaces again.
                            If the issue now pops up again, you'll know what to do ^^

                            No "help me" PM's please. Use the forum, the community will thank you.
                            Edit : and where are the logs ??

                            hiflyr777H 1 Reply Last reply Reply Quote 0
                            • stephenw10S
                              stephenw10 Netgate Administrator
                              last edited by

                              Hmm, I'd suggest looking at an MTU issue but the TCP handshake is all small packets and even that's failing....

                              Can you open a TCP connection to any host in that subnet? ews.netgate.com or www.pfsense.org

                              If you see the syn-ack coming back from those hosts but pfSense never sends an ack it must be some local filtering but it's hard to imagine what that could be....

                              hiflyr777H 1 Reply Last reply Reply Quote 0
                              • hiflyr777H
                                hiflyr777 @Gertjan
                                last edited by

                                @Gertjan Resetting back to defaults worked. I had full access to the package manager again. Thank you for the suggestion!

                                When I restored my backup XML file, it stopped working again. I have about 50 DHCP reservations in there, so I'm hoping not to enter them by hand again. (I can edit the XML file down to just the dhcp reservations, I suppose)

                                GertjanG 1 Reply Last reply Reply Quote 1
                                • GertjanG
                                  Gertjan @hiflyr777
                                  last edited by

                                  @hiflyr777 said in Package repo connection issues on fresh bare metal install:

                                  When I restored my backup XML file, it stopped working again.

                                  Now you know where the issue is located.
                                  Get the author of that file, the one who created all these settings. Have a talk, and you'll find out what went wrong ;)

                                  No "help me" PM's please. Use the forum, the community will thank you.
                                  Edit : and where are the logs ??

                                  1 Reply Last reply Reply Quote 0
                                  • hiflyr777H
                                    hiflyr777 @stephenw10
                                    last edited by

                                    @stephenw10 I did a trace and the SYN/ACK was coming back to my firewall where it wasn't sending an ACK back.

                                    @Gertjan suggested a reset and that worked for packages but something in my XML messed it up again. So I'll take what I can from that XML file (dhcp reservations at least) and configure the rest by hand.

                                    Thank you for your support!

                                    1 Reply Last reply Reply Quote 0
                                    • stephenw10S
                                      stephenw10 Netgate Administrator
                                      last edited by

                                      Hmm, about the only thing I could imagine would be a stateless firewall rule passing only TCP traffic to that subnet only. But that seems very unlikely!

                                      It must be something unusual in the config. I would search the file for 208.123.73 and see if anything in there is introducing some special handling.

                                      hiflyr777H 1 Reply Last reply Reply Quote 0
                                      • hiflyr777H
                                        hiflyr777 @stephenw10
                                        last edited by

                                        @stephenw10 Thanks again, I so appreciate you taking the time!

                                        And I'll comb through the XML file next.

                                        1 Reply Last reply Reply Quote 0
                                        • First post
                                          Last post
                                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.