DBus Client closing "due to inactivity"

[ChrisGV04]

Hi!

I developed an application for a customer that requires the back-end to connect to the company VPN to access the database. Since the application server is on a Linux server running Ubuntu 20.04, I installed openvpn3 to connect to it. So far, I have been able to connect to it successfully with no issues.

However, I noticed that every 30 minutes the connection to the VPN closed automatically, and when I viewed the journalctl logs for the process, I found these lines every 30 minutes after I reconnected the VPN manually:

[DATE] [NAME] org.freedesktop.DBus[1322]: {tag:13472519317941295639} Client INFO: Connection closing due to inactivity
[DATE] [NAME] org.freedesktop.DBus[1322]: {tag:13472519317941295639} Client INFO: Disconnected

I have tried adding a process to the back-end that runs every few minutes and queries the database using the VPN so that the connection stays open, which works for a couple of days, but then I get the exact same problem and my application crashes because it cannot connect to the database that's behind the VPN.

Does anybody know something I can do to prevent the DBus from closing automatically? It's really annoying having to connect to the VPN manually every couple of days and leave my customers with down time when the disconnection happens.

Thank you!

[dsommers]

This smells like you have a line in your config file saying inactive 1800 ... which would inhibit this behaviour. Or it might be this is being pushed by the server to the client.

You can get more info by boosting the log-level to 6:

 # openvpn3-admin log-service --log-level 6

I don't know how you start your VPN configuration, if it is a pre-imported configuration file (openvpn3 config-import) or if you kick off openvpn2 or openvpn3 session-start using the config file directly. In the case of the two latter ones, you need to add verb 6 to config file as well.

If you have pre-imported the configuration file, you can use openvpn3 config-manage --config $CONFIG_NAME --log-level 6.

You will see then see in the log which options are ignored, which are used and which are pushed by the server to the client.

If inactive is pushed by the server, you can add a config line saying:

 pull-filter ignore inactive

If inactive is present in your local config file - remove that line.

[ChrisGV04]

Oh wow. I've spent hours looking at different forums and I couldn't find this anywhere else, but it makes a lot of sense.

I added the line pull-filter ignore inactive to the config file and created a new session using the config-import and session-start approach and also set the log verbose to 6 as you said. The connection started as usual and is working fine, but when I checked the openvpn3 log I found this line:

2022-09-26 20:52:35 Client DEBUG: Ignored due to pull-filter: [inactive] [900] [7680]

I hope this is good news and that solves the problem. I won't be able to say for sure if it works until about 2 days or so, since the last time it disconnected by itself it lasted for 2 full days since I first started the session.

Thank you very much for your help! Fingers crossed to it being the solution 🤞🏽

[dsommers]

This should hopefully solve it. inactive 900 7680 basically means disconnect if there has been less than 7680 bytes of traffic within the last 900 seconds.

[ChrisGV04]

Hopefully it will! I'll mark this discussion as answered for now and if I find the error again later, I'll reopen it.

Thank you very much!

[dsommers]

Also a detail about "prevent the DBus from closing automatically". The log events you listed here is because the log event itself is captured by the dbus-daemon process; which is why it gets tagged with org.freedesktop.DBus. With the coming OpenVPN 3 Linux v19_beta release, it will use the native journald logging directly (and not pass it via syslog, where the log event origin may get mangled along the way on some Linux distros).

The log line itself indicates it is the openvpn3-service-client reporting sending the log event.

 {tag:13472519317941295639} Client INFO

The tag:.... part is a unique ID per openvpn3-service-* process. Which processes uses which tag IDs can be listed with openvpn3-admin log-service --list-subscriptions. If the ID is not found here, the related process should not be running.

The next "element" can be one of the following values:

Value	Process
Client	openvpn3-service-client
Config Manager	openvpn3-service-configmgr
Logger	openvpn3-service-logger
Network Configuration	openvpn3-service-netcfg
Session Manager	openvpn3-service-sessionmgr

And the last field (INFO) in this case is the verbosity level of the message (aka LogCategory in OpenVPN 3 Linux). Their relation to the log-level setting is defined here: https://github.com/OpenVPN/openvpn3-linux/blob/master/src/log/dbus-log.cpp#L62. Default log-level in most cases is 4, which means only messages in the LogCategory VERB1, INFO, WARN, ERROR and FATAL will be logged. FATAL is a special category which cannot be filtered out.

[ChrisGV04]

Thank you very much! That's very useful to understand the logs. I was just copy/pasting the command I found on several forums and that's how I found the cause of the disconnections.

It's my first time working with a VPN using the command line on a back-end so it has been a bit difficult to understand every problem. But overall I'm really amazed at how easy this tool has made this process, wouldn't know what to do without it. Thank you and the collaborators for the amazing work!