Rebuilding the blog and resolving the issue where only TCP communication from Starlink to ConoHa VPS fails to reach

6 min

自宅サーバーサーバーfreebsd
language: ja bn en es hi pt ru zh-cn zh-tw

Hello, I'm Munou.

It's been a while since the last update. Actually, some of the articles from the latter half of 2025 were lost, and that's how things stand now.

Codex

I've recently started using Codex, and the development experience is so good that I've fallen completely into the rabbit hole.

So, I re-architected my blog using Codex, moving away from Lume CMS, which I had been dissatisfied with for a long time.

While being able to write in Markdown for an SSG is nice, I ended up updating mostly through the browser, so I realized there was no point in going out of my way to write in my usual editor, vim.

Images were a particular problem, and I didn't feel like updating the blog casually...

The code is published here, but it's currently full of bugs.

GitHub - haturatu/alleycat: cms

GitHub - haturatu/ViMusic

It looks like I might be able to resume maintenance on it, so I've started maintaining it again. Surprisingly, when I replied to someone on Reddit looking for a fork, it turned out to be the same person who had opened an issue on my repository.

The world is a small place, isn't it?

Losing Network Reachability to ConoHa VPS

Then, a problem suddenly occurred.

It seems like a Path MTU Black hole was occurring. It was truly strange; while things requiring UDP communication like WireGuard or DNS servers were reachable, anything requiring TCP like SSH or HTTP communication was completely down.

Since the ConoHa VPS itself is hosted on FreeBSD, I looked into it and found information suggesting that the problem could be solved by using the scrub feature of the packet filter ( pf ) to normalize packets. I configured it as follows:

set skip on lo
set block-policy drop
exsrv1 = dummy
insrv1 = dummy
insrv2 = dummy
wireguard_clients="{ dummy, dummy, dummy }"
wanint="vtnet0"
wg_ports="{51820}"
scrub in on $wanint all random-id max-mss 1360
scrub out on $wanint all random-id max-mss 1360
~~~

With this, both inbound and outbound traffic are normalized, and the packet segment size becomes 1360.

Strange Points

There is speculation that the cause of this might be something wrong with Starlink's CGNAT.

$ mtr -T -P 443 -n -r -c 2 163.44.113.145
Start: 2026-02-24T00:13:53+0900
HOST: thepassenger                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%     2    1.4   1.5   1.4   1.6   0.1
  2.|-- 100.64.0.1                 0.0%     2   19.3  19.4  19.3  19.4   0.1
  3.|-- 172.16.251.26              0.0%     2   20.1  23.4  20.1  26.8   4.8
  4.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  5.|-- 206.224.70.186             0.0%     2   25.9  22.3  18.8  25.9   5.0
        206.224.70.182                   
  6.|-- 210.171.225.229            0.0%     2   23.0  22.7  22.4  23.0   0.4
  7.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  8.|-- 172.71.208.15              0.0%     2   24.9  23.1  21.3  24.9   2.5
        162.159.109.42                   
  9.|-- 172.71.4.38                0.0%     2   21.9  23.3  21.9  24.8   2.1
        172.64.212.62                    
 10.|-- 172.71.4.35                0.0%     2   63.3  43.8  24.2  63.3  27.7
        172.70.221.227                   
 11.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
 12.|-- 172.70.165.3               0.0%     2   44.7  39.8  35.0  44.7   6.9
 13.|-- 150.95.7.204               0.0%     2   33.4  34.0  33.4  34.6   0.8
 14.|-- 150.95.7.139               0.0%     2   39.2  50.3  39.2  61.4  15.7
 15.|-- 150.95.7.147               0.0%     2   36.6  37.2  36.6  37.9   0.9
 16.|-- 163.44.113.145             0.0%     2   34.2  35.8  34.2  37.5   2.3
$ tracepath -n -m 30 163.44.113.145
 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.1.1                                           1.347 ms 
 1:  192.168.1.1                                           1.293 ms 
 2:  100.64.0.1                                           53.580 ms asymm  3 
 3:  172.16.251.26                                        37.025 ms 
 4:  206.224.70.208                                       34.552 ms (incomplete router returned corrupted data) asymm  7 
 5:  206.224.70.184                                       37.307 ms 
 6:  210.171.225.229                                      34.518 ms 
 7:  no reply8:  172.71.4.43                                          34.303 ms 
 9:  162.159.109.87                                       39.922 ms 
10:  162.159.109.55                                       33.535 ms 
11:  No response
12:  172.70.165.3                                         56.395 ms asymm 11 
13:  150.95.7.204                                         46.647 ms asymm 10 
14:  150.95.7.139                                         66.797 ms asymm 11 
15:  150.95.7.147                                         46.542 ms asymm 12 
16:  No response
17:  No response
18:  No response

In the first place, I had the impression that even if the default packet size for Starlink and my network environment was 1500, TCP communication would handle it gracefully, so I didn't understand why this suddenly happened this month between ConoHa VPS <-> Starlink.

If the original Starlink CGNAT was faulty, I think it wouldn't have been strange for the problem to occur much earlier, but it's such a mysterious phenomenon that it's been bugging me for a long time.

Related Posts