yellow-leaves
So it's now been two night since I've Set Dynamic code loading via Storage Restricted for Wireguard on owner/Primary as well.

On the first night wireguard remained connect, but during the second night wireguard was terminated!
Unfortunately the logcat for wireguard in the owner profile was empty so i was unable make a definitive correlation.
I have however no recollection of this ever happening before so this is unlikely to be a coincidence.

Meanwhile wireguard running in the secondary profile has also been disconnecting every night as usual/expected.

If wireguard in the owner profile continues to terminate every night just like it does in the secondary profile i will assume that DCL via storage is required and enable it for both profiles and hope that the issue goes away.

    Hi - I think I might have a similar issue.

    I've used the Proton VPN app for a few years on GrapheneOS without issue. Rarely, almost never dropped.. but in the past week I've been waking up to the VPN disconnected. Always in the morning, every morning, and never once during the day.

    I'm using a Pixel 7 Pro and WireGuard protocol in my VPN settings. Did anyone figure this out?

      Viewpoint0232
      Do you mean DCL via storage?
      It turns out Wireguard terminating in the owners profile was a one time thing, so I've just left it disabled in both profiles.

        RootCron Interesting, this is about the same time I started having issues, Are you running proton in Owner or secondary profile?
        Are you establishing a wireguard or openvpn connection (not sure if proton is wireguard only or if they do openvpn as well)

            My most recent attempt to resolve this issue where to attempt to switch to my VPN providers own VPN client but the UI was absolutely horrible and it forced me to a have an active none VPN:ed connecting in order to let me register it as a system VPN provider (I tried to disable the old VPN provider and register the new one while in airplane but it was impossible.)

            I believe my next step is to try out wgtunnel although I had previously decided against as using it introduces additional link in my chain of trust but now It's my best option(protocol developer, VPN provider, android client developer etc).

            p.s. tried using app manager to detect if wireguard or any other app was using an abnormal amount of ram but alas i was unsuccessful as root or adb is required to gain access to such info.
            https://github.com/MuntashirAkon/AppManager?tab=readme-ov-file

            yellow-leaves

            I'm running the official ProtonVPN app in owner mode, and have no other profiles.

            ProtonVPN was set to smart protocol and had chose Wireguard - so I've set it to fixed openvpn and will see if that makes a difference tomorrow morning.

              So, first overnight experiment after changing ProtonVPN app to openvpn, rather than Wireguard. I never woke up to a disconnected VPN, like I have in the last week.

              I wonder what it is about "overnight" that causes the Wireguard connection to fail. Maybe it's not "overnight" as such, but if the screen isn't unlocked for X hours, or something like that. With GrapheneOS, I'd imagine people using always-on VPNs is common, but I'm not hearing any widespread issues about this. I'm thinking maybe it's a bespoke config or app we have installed that's causing the issue.

              Other than a standard Pixel 7 Pro, my setup is pretty standard. I've no additional profiles or weird configs. One thing is my phone always charges overnight, and very rarely during the day. Could it be the charging that's causing this? Just thinking out loud!

                RootCron
                I don't now about your chairing theory, if anything the system should go into high power mode where there is no need for apps to conserve resources.
                this documents seem to indicate that something like this is happening: https://developer.android.com/training/monitoring-device-state/battery-monitoring

                Something that is more interesting to me is the fact that your pixel 7 pro has twice the ram of my 6a,
                12 GB ram vs 6GB ram.
                I used app manager to check the ram usage of my 6a and after a 40 hours (but it's virtually the same after reboot) of uptime my ram usage looks like this:
                Memory 5.78/5.87 GB
                Swap 2.8 GB/ 3.22 GB

                I wonder what your figures looks since you have twice the amount of ram and only one user profile while I have two active profiles.
                I might be hitting the limits of my device (or the android system is just opportunistically filling it up) since I have only 6 GB of RAM but with twice that doubt it could be an issue.

                https://github.com/MuntashirAkon/AppManager

                  Since the Android 15 release Wireguard appears to crash (or force-close) for me too.
                  From what I've seen it might be related to Seedvault backups, at least in my case.

                  I haven't tested it yet, but maybe it helps to exclude WireGuard from the Backups:
                  System -> Backups -> Status (Last backup: ...) -> 3dot menu top right -> Exclude Apps

                    Cypher

                    Very interesting you mention Seedvault backups!

                    Around the same time my VPN started dropping overnight, I had a notification about Seedvault backups backing up Firefox. This notification was frozen, couldn't be swiped away or expanded in any way. A reboot was the only way to get rid of it. I had to disable Seedvault backups to stop it.

                    These two issues are the only semi significant issues I've experienced in years of GrapheneOS use, and seems likely they're related somehow. I'll re-enable the Wireguard option on my ProtonVPN app, and see how it fares overnight with Seedvault disabled.

                    I don't know much about Seedvault, but if it runs overnight that'd explain why people are waking up to disconnected VPNs too.

                        RootCron
                        That is what happened for me too: Seedvault was at "Firefox" right after my WireGuard was disconnected. (I checked the SeedVault notification maybe 2-5 seconds after the VPN disconnection notification appeared.)
                        But after a minute or two Seedvault continued with another few apps and finished without errors.

                        Maybe WireGuard was stopped by Seedvault and Firefox just happens to be the next app to back up for both of us...? But it feels like too big of a coincidence.

                            Can confirm it's Seedvault. I exempted the Mullvad app from the backup and last night my VPN wasn't disconnected.

                            Agreed, my ProtonVPN app hasn't disconnected its Wireguard connection overnight since disabling Seedvault.

                            Very interesting that about seedvault, I have it set up my self.

                            I'm going try see if this exemption helps as well, though I can't be bothered right now as wgtunnel haven't been disconnecting like the official wireguard app and I can't be bother to switch back right now.
                            In addition I'm gonna have to check if wgtunnel is excepted from seedvault backups and maybe that's why it's kept alive, though it also a runs a perpetual notification which is bound to help.

                              yellow-leaves

                              From reading the comments on those issues, only the app's main process is killed. If the VPN tunnel is a separate process, then it continues running.

                              Apparently Mullvad recently switched to a single process, which caused more people to notice the issue.

                              Wgtunnel probably uses a separate process.

                                  Probably9857

                                  I see, backing up VPN apps makes little sense anyway so if excluding ones VPN from seedvault resolves this issue then everyone ought to do it.