VPN Freezes entire computer and you have to force restart

Which Linux distro are you using?
Fedora

Which release version?
Fedora Linux 44

Which kernel are you using?
7.2.7-200.fc44.x86_64 (64-bit)

Which BIOS version are you using?
03.02

Which Framework Laptop 13 model are you using?
Framework 13 Pro, Intel® Core™ Ultra X7 358H
Laptop 13 Pro (Intel Core Ultra Series 3)

My issue:
Any time I use TCP on a VPN (Windscribe and ProtonVPN), if I close the laptop lid to put it to sleep while the VPN is on, it freezes the entire laptop. Can’t do anything, can’t move the mouse, shut down, no display updates, can’t switch TTY, caps lock key doesn’t light up, can’t do anything.

Doesn’t happen on Wireguard, VPN brand is irrelevant as long as it’s TCP, and doesn’t happen if I just turn off the VPN beforehand (which I forget plenty of times, so I sometimes have to force restart my laptop multiple times in a day).

From how hot it is I’m guessing it’s running all of its processing power doing SOMETHING, I don’t know what. I HAVE to force-restart it, simply waiting does nothing.

Does anyone have any tips on how to make it… not do that? Can’t not use TCP.

I know it’s the google ai overview which should be double checked but it’s a worthwhile starting point:

Could you maybe attach a screenshot?

WireGuard uses UDP under the hood, so all traffic is UDP. Seems like you should create a script at /usr/lib/systemd/system-sleep/ to turn off your VPNs before your system goes to sleep.
Something like

#!/bin/bash
case $1 in
    pre)
            protonvpn disconnect
    ;;
    post)
            whatever-you-want-when-the-system-turns-on
    ;;

This is the output. Comes with a warning to use caution. Backup your system beforehand just in case.


When Fedora 44 attempts to enter a suspend state while a active TCP-based VPN (such as OpenVPN, WireGuard over TCP, or AnyConnect) is running, the crash is usually caused by a network interface deadlocking the kernel network stack.
As systemd-logind tries to pause network activities for the sleep state, the active TCP socket waits on a handshake or times out aggressively. This causes an unkillable network process or a kernel panic, resulting in a black-screen crash instead of normal sleep.

Step 1: Tell systemd to bring down the VPN before suspending

The cleanest fix is to create a systemd pre-suspend hook that forces the VPN to disconnect before the laptop powers down the network adapters.

Open your terminal and create a new script file

sudo nano /usr/lib/systemd/system-sleep/vpn-disconnect.sh

Paste the following script (this example works if you manage your VPN via NetworkManager)

#!/bin/sh
case "$1" in
    pre)
        # Find any active VPN connections and disconnect them
        ACTIVE_VPN=$(nmcli -t -f NAME,TYPE connection show --active | grep vpn | head -n1 | cut -d: -f1)
        if [ -not -z "$ACTIVE_VPN" ]; then
            logger "Pre-suspend: Disconnecting active VPN: $ACTIVE_VPN"
            nmcli connection down id "$ACTIVE_VPN"
            sleep 1 # Give the network socket a second to close gracefully
        fi
        ;;
esac

(Note: If you run OpenVPN directly from the terminal rather than NetworkManager, replace the inner block with pkill openvpn.)

Make the script executable

sudo chmod +x /usr/lib/systemd/system-sleep/vpn-disconnect.sh

Step 2: Ensure systemd doesn’t ignore inhibitors

Sometimes NetworkManager or desktop modules try to block sleep until the connection is safely torn down, but systemd forces the lid-close suspend anyway, triggering the crash.

Edit your login settings

sudo nano /etc/systemd/logind.conf

Find the following line, uncomment it (remove the #), and ensure it is set to yes

LidSwitchIgnoreInhibited=yes

Alternatively, if you prefer your laptop never goes to sleep while the lid is closed (acting like a workstation server), change the behavior to ignore:

HandleLidSwitch=ignore

Save the file and restart the logind service:

sudo systemctl restart systemd-logind

Step 3: Switch from TCP to UDP (If possible)

TCP VPN profiles are notoriously fragile under Linux sleep cycles because TCP demands strict packet acknowledgments and state tracking. If your VPN provider allows it, switch your connection protocol from TCP to UDP. UDP doesn’t maintain an active, stateful virtual circuit, allowing Fedora’s kernel to cleanly suspend the network interface without waiting for a socket response.

Oh, that’s simple. Thanks!
Although I wonder why simply closing my lid can make it freeze and crash like this, but at least it’s fixed now.

1 Like

Yeah, sometimes having a daemon that runs in the background whenever your pc goes to sleep can cause some issues.

Why would you post an AI output on a forum? I’m sure the original poster is more than capable of talking to an AI themselves.

If you read the thread properly you would’ve seen the post where they said they couldn’t see the overview content in their region which is why they asked me to post it.

1 Like

I have seen problems like this relating to suspend and some network devices.
If you could raise a bug so that someone could easily reproduce this problem. Someone could then fix the problem.
There is not enough information here for someone to repeat it.
In software development, the hardest part is getting the bug reproduced on someone elses computer. Once that is achieved, the bug fix is normally really easy to fix.

FYI. The linux kernel has some infinite spinlocks in the network resume path. I think those need fixing, and this bug could cause someone to finally fix them.

Sorry I’m not too familiar with the Linux community, could you point me to where I could submit this as a bug, or help out somewhere?

As to reproduce it, it really is as simple as the post states.
Download a VPN (I use Windscribe and ProtonVPN, works with either). Connect with the TCP protocol while connected to WiFi (my exact conditions were with WiFi, I don’t know about other conditions). Close the lid and let it sleep. Open the lid and let it wake up. Wait for it to auto-connect to the WiFi. And it just freezes everything.

I don’t know where this would be repoted, to be honest. Maybe, I would start with reporting it to ProtonVPN to start with(?).

Hm it’s just not a ProtonVPN bug though, it’s a problem with the openVPN driver I’m pretty sure?

Just checking: did you manage to resolve it with a script in the end?

If so - could you post what you did and the script you used in here for future reference/ to help others?