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.