Troubleshooting certain websites that fail to load after a successful VPN connection
Summary
After upgrading from Debian 11 (Bullseye) to Debian 12 (Bookworm), SSTP VPN connections may establish successfully, but some HTTPS websites fail to load. For example: google.com may work but news.yahoo.co.jp does not.
Observed Symptoms
· SSTP VPN connection establishes successfully.
· DNS resolution works normally.
· Some websites work (for example, Google).
· Some websites fail to load (for example, Yahoo Japan).
· Firefox and Edge exhibit the same behavior.
· curl -v stalls after sending the TLS ClientHello.
Example:
$ curl -v https://www.yahoo.co.jp
* Trying 182.22.23.252:443…
* Connected to www.yahoo.co.jp (182.22.23.252) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
…
No further output is displayed.
Affected Versions
Environment where the issue was reproduced:
| Package | Version | Architecture | Description |
| libsstp-api-0 | 1.0.18-1 | amd64 | SSTP client API library |
| network-manager-sstp | 1.3.0-2 | amd64 | NetworkManager SSTP plugin core |
| network-manager-sstp-gnome | 1.3.0-2 | amd64 | NetworkManager SSTP GNOME interface |
| sstp-client | 1.0.18-1 | amd64 | SSTP VPN client |
Root Cause
The issue appears to be caused by an MTU / PMTU problem on the PPP interface created by SSTP. Although the VPN tunnel connects successfully, larger TLS packets are dropped somewhere along the tunnel path.
Reducing the MTU on the PPP interface immediately resolves the problem.
Troubleshooting
1. Show Current MTU
ip link show ppp0
Adjust the interface name if your system uses ppp1, ppp2, etc.
Example:
ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500
2. Test Lower MTU
Temporarily lower the MTU:
sudo ip link set dev ppp0 mtu 1420
You may wish to test multiple values:
| MTU values to test |
| 1450, 1440, 1430, 1420, 1400, 1350, 1300 |
Use the highest value that remains stable.
3. Verify Fix
Test previously failing sites:
curl -v https://www.yahoo.co.jp
or
curl -4 -I https://www.yahoo.co.jp
If the website now loads correctly, the MTU issue has been confirmed.
Permanent Fix
Create a PPP ip-up Hook
Create the following file:
sudo nano /etc/ppp/ip-up.d/99-sstp-mtu
Contents:
#!/bin/sh
/usr/sbin/ip link set dev “$1” mtu 1420
logger “PPP ip-up: set MTU 1420 on $1”
Make it executable:
sudo chmod 755 /etc/ppp/ip-up.d/99-sstp-mtu
Reconnect the VPN
Disconnect and reconnect the SSTP VPN connection.
Confirm the Fix
Verify MTU
ip link show ppp0
Expected output:
mtu 1420
Verify the Hook Executed
journalctl -b | grep “PPP ip-up”
Expected output:
PPP ip-up: set MTU 1420 on ppp0
Final Notes
· The working MTU discovered in this environment was 1420.
· If desired, test larger values and keep the highest value that works reliably.
· The symptoms only became apparent after upgrading from Debian 11 (Bullseye) to Debian 12 (Bookworm).
· Lowering the PPP MTU resolves TLS handshake failures for affected websites.
Quick Reference
Show MTU
ip link show ppp0
Temporarily Change MTU
sudo ip link set dev ppp0 mtu 1420
Verify Fix
curl -v https://www.yahoo.co.jp
Permanent Fix Script
sudo nano /etc/ppp/ip-up.d/99-sstp-mtu
sudo chmod 755 /etc/ppp/ip-up.d/99-sstp-mtu
Confirm Hook Execution
journalctl -b | grep “PPP ip-up”
Keywords: Debian 12, Bookworm, SSTP, SSTP VPN, network-manager-sstp, TLS handshake, MTU, PMTU, PPP, pppd, Yahoo Japan, curl, VPN troubleshooting.