Package repo connection issues on fresh bare metal install
-
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.
-
What NIC are you using currently if you don't yet have the 2.5G re driver?
-
@stephenw10 I have an i225 which just works
-
@stephenw10 See screenshot below for the Test Port.
Would you like a shot of the routing table?
-
Can you ping those IP addresses? If so does the latency look correct from where you are?
Try running:
pfSense-repocorpfSense-repoc -DThat connects to ews.netgate.com in the same subnet.
-
@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 -
@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. -
@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 -
@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 :
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 ?? -
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....
-
@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)
-
@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 ;) -
@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!
-
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.73and see if anything in there is introducing some special handling. -
@stephenw10 Thanks again, I so appreciate you taking the time!
And I'll comb through the XML file next.
