Duckduckgo unreachable

Looking closely at this capture:

No.	Time	        Source	        Destination	Protocol Length	Info
1038	0.000000000	192.168.3.102	79.125.108.55	TCP	74	49290 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3428693430 TSecr=0 WS=128
1051	0.250914544	192.168.3.102	79.125.108.55	TCP	74	49292 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3428693681 TSecr=0 WS=128
1063	0.772308128	192.168.3.102	79.125.108.55	TCP	74	[TCP Retransmission] 49290 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3428694453 TSecr=0 WS=128
1086	0.236667679	192.168.3.102	79.125.108.55	TCP	74	[TCP Retransmission] 49292 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3428694690 TSecr=0 WS=128
1117	1.866666555	192.168.3.102	79.125.108.55	TCP	74	[TCP Retransmission] 49290 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3428696557 TSecr=0 WS=128
1118	0.213332249	192.168.3.102	79.125.108.55	TCP	74	[TCP Retransmission] 49292 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3428696770 TSecr=0 WS=128
1312	3.840001835	192.168.3.102	79.125.108.55	TCP	74	[TCP Retransmission] 49290 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3428700610 TSecr=0 WS=128
1315	0.213333979	192.168.3.102	79.125.108.55	TCP	74	[TCP Retransmission] 49292 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3428700823 TSecr=0 WS=128
1508	7.893330483	192.168.3.102	79.125.108.55	TCP	74	[TCP Retransmission] 49290 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3428708717 TSecr=0 WS=128
1521	0.213334786	192.168.3.102	79.125.108.55	TCP	74	[TCP Retransmission] 49292 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3428708930 TSecr=0 WS=128
1883	17.493335653	192.168.3.102	79.125.108.55	TCP	74	[TCP Retransmission] 49290 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3428726423 TSecr=0 WS=128
1884	0.000009238	192.168.3.102	79.125.108.55	TCP	74	[TCP Retransmission] 49292 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3428726423 TSecr=0 WS=128
3415	32.426651767	192.168.3.102	79.125.108.55	TCP	74	[TCP Retransmission] 49290 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3428758850 TSecr=0 WS=128
3416	0.000006393	192.168.3.102	79.125.108.55	TCP	74	[TCP Retransmission] 49292 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3428758850 TSecr=0 WS=128

It looks like we have two threads, one sending from port 49290 and the other from 49292. The second one follows the first initially by 250ms, then 213ms for a while, and finally by only some microseconds. I guess this confuses the poor server.

Do you have a DNS cache installed like dnsmasq? If so, it’s possible a stale IP address has been cached. Restarting the service should fix it. Though if your PC has rebooted since this problem started, I doubt it is the cause.

Nope, nothing like that AFAIK. Anyway, I’ve rebooted my PC yesterday at least.

It could be that one is for HTTP/1.1 and the other one is for HTTP/2. Did you use a browser, wget, or curl? You could try nc -v duckduckgo.com 443 (you need the openbsd-netcat package).

I used Palemoon browser, a FireFox clone.
Good point. With nc I only have one thread, and the timeouts are as expected: 1, 2, 4, 8, 17, 32 seconds.
I’m guessing I don’t get the double-thread syndrome with lite.duckduckgo.com because the SYN,ACK comes within 27 milliseconds.
That still leaves the question of why duckduckgo.com doesn’t respond to the SYN. Can we say for sure that the SYN,ACK response is not being tossed on my machine?

I’m not sure… you said it works on a different computer in the same house. Can you test it again? Wireshark should show all packets. Maybe it’s the firewall in the router?

Yup, it still works in Palemoon on my Windoze7 machine. nc also works on my FreeBSD machine. I looked at my router, and didn’t see anything untoward such as a filter for duckduckgo.com.

In that case please try the live session of any linux distribution and see if it works there. And then you could possibly connect that machine to your FreeBSD machine, configure static IP, routing to see (with tcpdump) if the packets are actually leaving your machine.

Wow, that’s huge…

Try lowering MTU on enp0s1 to lets say 1450.
Disable and re-enable the interface after doing so.

He did.

Yup, lowered mtu to 1450. No joy.

Can you run dig duckduckgo.com lite.duckduckgo.com +short?

To be fair, WireShark shows the packets going out, but maybe there’s some software lower down that is suppressing it, or in the router.

I don’t have dig. What package would that be in?

Bind.
.
If your router has an option to block fragmented packets (or something like “clear DF bit”), disable it.

= dig duckduckgo.com lite.duckduckgo.com +short
40.114.177.156
duckduckgo.com.
40.114.177.156

If you run nc -v lite.duckduckgo.com 443 and nc -v duckduckgo.com 443, does any of them print “Connection to … succeeded!”?

lite succeeds, plain vanilla does not.

What about nc -v 40.114.177.156 443?

succeeded, because that’s lite.