Risk of leaks when restarting bluetit?

[pHxaq 0]

Hello, sometimes I leave my notebook idle for a while and when I come back I see my vpn connection stopped working. When that happens, I need to change to superuser and run

/etc/init.d/bluetit restart

Sometimes I do that while the webpages are still loading (which is the moment when I realize that airvpn disconnected).
My question is: while I restart bluetit, is my web traffic leaking? (I have option networklockpersist = on)

Thanks.

[Staff 10015]

13 hours ago, pHxaq said:

Hello, sometimes I leave my notebook idle for a while and when I come back I see my vpn connection stopped working. When that happens, I need to change to superuser and run

/etc/init.d/bluetit restart

Sometimes I do that while the webpages are still loading (which is the moment when I realize that airvpn disconnected).
My question is: while I restart bluetit, is my web traffic leaking? (I have option networklockpersist = on)

Thanks.

Hello!

Yes, there is a small likelihood that leaks will occur: when you restart Bluetit, first Bluetit stops and the previous firewall rules, policy settings included, are restored. Then Bluetit starts and Network Lock rules are enforced. The time between those actions varies from system to system, but in general a few tenths of a second are required. If, during those tenths of seconds, a process manages to create a new socket and send out data, or use a pre-existing one whose communications did not "time out", you will have a leak.

A safer approach is to disconnect and reconnect with Goldcrest. By using Goldcrest to send commands to Bluetit, the persistent network lock is not disabled at any stage: the rules are of course changed, but the whole process is carried out while maintaining the "drop" policy.

Kind regards
 

[pHxaq 0]

I guess I exposed my not-so-relevant data then
thanks for the reply

[Staff 10015]

1 hour ago, pHxaq said:

I guess I exposed my not-so-relevant data then
thanks for the reply

Hello!

Maybe, or maybe not, as the probability is small given the tiny time frame, but from now on you can easily avoid the hazard. Shutting down the whole daemon just to perform a re-connection is indeed a disproportionate and unnecessary action, just send commands with Goldcrest to do it.

Kind regards