Solved Cannot connect to freebsd.org on FreeBSD 12

Hello!

I've some sort of a situation on a laptop device trying to access freebsd.org (and lists.freebsd.org) from my home wifi network. Thankfully forums.freebsd.org works fine. All other websites seem to load fine. If I move this laptop to another network, freebsd.org works without issues on the same installation of fbsd. If I boot into another OS on this laptop, I can access freebsd.org just fine. All other devices, such as my phone, can access freebsd.org from this home network without problems.

What can I try to do in order to troubleshoot this situation?

PS - How do I make sure that no firewalls are running and blocking it on this specific network? I don't remember setting up any firewalls, but I'll check again.

Thanks!
 
If I boot into another OS on this laptop, I can access freebsd.org just fine. All other devices, such as my phone, can access freebsd.org from this home network without problems.
We sometimes block certain addresses (and in some case even whole ranges) to combat abuse. But if you can access the site from other computers in the same network then we can conclude this is not the case.

From the "broken" FreeBSD machine, can you try to resolve freebsd.org? Try drill freebsd.org. Maybe there's an issue with resolving.
 
Hi,

Here's the output of for the drill and ping commands, seems like DNS resolution works fine:
drill:
Bash:
[user@somebox ~/cmu/18349]$ drill www.freebsd.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 33638
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; www.freebsd.org.    IN    A

;; ANSWER SECTION:
www.freebsd.org.    60    IN    CNAME    wfe0.nyi.freebsd.org.
wfe0.nyi.freebsd.org.    1452    IN    A    96.47.72.84

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 85 msec
;; SERVER: 75.75.75.75
;; WHEN: Fri Sep 13 08:56:27 2019
;; MSG SIZE  rcvd: 72

ping:
Code:
[user@somebox ~/cmu/18349]$ ping www.freebsd.org
PING wfe0.nyi.freebsd.org (96.47.72.84): 56 data bytes
64 bytes from 96.47.72.84: icmp_seq=0 ttl=55 time=32.219 ms
64 bytes from 96.47.72.84: icmp_seq=1 ttl=55 time=36.264 ms
64 bytes from 96.47.72.84: icmp_seq=2 ttl=55 time=22.834 ms
64 bytes from 96.47.72.84: icmp_seq=3 ttl=55 time=21.467 ms
64 bytes from 96.47.72.84: icmp_seq=4 ttl=55 time=32.646 ms
^C
--- wfe0.nyi.freebsd.org ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 21.467/29.086/36.264/5.851 ms
 
Yep, DNS looks good. Ping is good too. Lets try to fetch the main page; fetch -o /tmp/index.html http://www.freebsd.org
 
Yep, DNS looks good. Ping is good too. Lets try to fetch the main page; fetch -o /tmp/index.html http://www.freebsd.org

As soon as that command is entered, it just waits there for a long time without any output, and finally says:
Code:
fetch: http://www.freebsd.org: Operation timed out
 
Interesting. Did you perhaps configure a proxy? Check the HTTP_PROXY (or http_proxy) environment variables.

Another test, which doesn't use a proxy even it's been set; nc -zv www.freebsd.org 80
 
Interesting. Did you perhaps configure a proxy? Check the HTTP_PROXY (or http_proxy) environment variables.

Another test, which doesn't use a proxy even it's been set; nc -zv www.freebsd.org 80

Timed out, and it doesn't seem like I've a proxy set up. But it also says 'No route to host'.

Code:
[user@somebox ~]$ echo $HTTP_PROXY

[user@somebox ~]$ echo $http_proxy

[user@somebox ~]$ nc -zv www.freebsd.org 80
nc: connect to www.freebsd.org port 80 (tcp) failed: Operation timed out
nc: connect to www.freebsd.org port 80 (tcp) failed: No route to host
 
Ok, those might be caused by a firewall, we pretty much ruled everything else out. It's a little tricky to check though, there are three different firewalls that could be enabled.

Any or all of these may just give an error:
Code:
pfctl -sr   # Checks PF
ipfw list   # Checks IPFW
ipfstat     # Checks IPF
 
Ok, those might be caused by a firewall, we pretty much ruled everything else out. It's a little tricky to check though, there are three different firewalls that could be enabled.

Any or all of these may just give an error:
Code:
pfctl -sr   # Checks PF
ipfw list   # Checks IPFW
ipfstat     # Checks IPF

So I ran all the three commands, and they all return errors, which is in correspondence with what I thought I did (never set up firewall rules).

Code:
[root@somebox ~]# pfctl -sr
pfctl: /dev/pf: No such file or directory
[root@somebox ~]# ipfw list
ipfw: retrieving config failed: Protocol not available
[root@somebox ~]# ipfstat
open(IPSTATE_NAME): No such file or directory
[root@somebox ~]#
 
I've been having the same problem, at least from home. It's interesting as I can still reach the site via Tor, but not directly. I'm actually more suspicious of my ISP doing something stupid (it wouldn't be the first time!), but with my quick check using wireshark nothing looked too odd. I can see the start of a TLS session, but trying to debug that from within a packet sniffer is painful at best.

So I don't yet know what's going on, but I need to find some better tools to troubleshoot TLS, as I've rarely if ever had to do so in the past. Any suggestions are welcome.

Edit: Actually I just took another look. It seems this happening when the client (me) is trying to set up a TLS session, in that I'm sending a client hello, which is acknowledged (as in layer 4, a segment with the ACK flag set), but I never see a higher layer acknowledgement, i.e. a server hello. Very strange.

I can see only two things that likely would cause this:
  • FreeBSD.org has some syn-proxying firewall which is allowing the initial TCP connection, but it's then blocked later on by the web server/reverse proxy. If this is the case, it begs the question, why isn't the firewall doing the filtering before traffic hits the server/proxy?
  • Somewhere between me and the FreeBSD servers some traffic manipulation (blocking, in this case) is going on, and the server hello, or possibly my client hello, is simply being dropped/filtered.
Either way something's rotten. Who's your ISP, lrx33?
 
For me this happens way before there's any attempt to even set up TLS, at the initial TCP SYN that is sent out. No SYN ACK is received for it. I attach two images: The first is for my home network, where I'm behind a NAT (10.0.XX.XX address) and it fails in this case, receiving no ACK for the initial TCP SYN and then keeps retransmitting until timing out.
The second is from my school network where my school has a large block of IPs, and I get a public IP assigned there. It works without issues there, and as the wireshark dump summary shows, the initial TCP SYN is ACK'd and then everything just works as it should.

96.47.72.84 is the IP returned for freebsd.org.

fbsd-fail-home.png Fail from home network, behind a NAT. FWIW, my provider is Comcast (XFINITY)

fbsd-succ-school.png Success from school network, public IP. Works without issues.

So it seems like it has something to do with a NAT + SYN filtering of some sort either by ISP or freebsd.org webserver server?
I wonder if it would make any difference if I would turn off NAT and just plug a single machine into the network instead..

`Orum : Can you describe what your setup looks like in more detail? And who's your ISP?

EDIT: I just realized that other devices on my home network (behind NAT) work fine (Android, Ubuntu, iOS, etc) when trying to open freebsd.org. So it is somewhat related to NAT + FreeBSD behind NAT (and maybe the ISP somehow?). Is there any reason why a SYN packet going from a NATtted freebsd would be any different from a SYN packet going out from a NATted ubuntu (Both on the same home network)?
 
I have news! I can now access freebsd.org on my freebsd machine from my home network!
I enabled IPv6 explicitly in my /etc/rc.conf with
Code:
ifconfig_rl0_ipv6="inet6 accept_rtadv"
rtsold_enable="YES"
.. and after a reboot, I can access freebsd.org.

It seems to me now that for some reason, since my wireless router is IPv6 enabled, it wasn't allowing IPv4 SYNs to go through. I'm not sure why my ISP(?) would want to do this.

Thanks for the help in troubleshooting this, SirDice!
 
I'm on at&t at home, but they don't give me an IPv6 address, only IPv4. "Why provide a paved road when you can use a cobblestone one?" Oh the joys of living in the US...

I'm most suspicious this is due to some blocking/filtering/misconfiguration from them, but without being able to view traffic from both ends (or be certain that freebsd.org isn't blocking me, though I'm not sure why they would) I can't say for sure.
 
`Orum on mine, I can add IPv6 by accessing and configuring my router.
You can't simply "add" IPv6 support to your router to make your ISP support routing IPv6 as well. They have no DHCPv6 or NDP, and short of tunnels I have no way to use IPv6 on the internet. In any case, my problem appears to be due to a different cause than yours.

In the short term I'll just tunnel through work or use Tor, but I'd like to get this sorted out when I have more time to do so.

Edit: Seems at some point this was fixed with no changes on my end, and I can now get there without issue.
 
Last edited:
Back
Top