What triggers a 'MANAGEMENT: Client connected from /var/run/openvpn_mgmt' and initiates a 'CMD kill <user>'?

Salut Koen,

If you run the version command on the shell, were the last Up2Dates applied just before this started happening?  If so, you might want to restore the backup made at the beginning of that last application of Up2Dates and then redo the modifications since then.  It's rare but not unknown that an Up2Date process will mangle a portion of a configuration database.

The other thing that folks have reported was related to using the same port in a NAT rule.  I like to use UDP 1443 with the SSL VPN instead of TCP 443.

NOTE 2019-04-26: One reason to stay with the TCP 443 default is that your cellular data provider might block UDP.  My AT&T iPhone XS was unable to establish a working tunnel when using UDP 443 or UDP 1443.  Everything worked perfectly with TCP 443.

If neither of those resolves your issue, someone will need to take a closer look in your device.  It may be time to open a case with Sophos Support.

Cheers - Bob

Hi,

don't know if the issue persists. 

We're running into this issue also and the solution was easy here at the end..

We've added some DNS-Hosts to one profile. One of them was a cloudfront endpoint with more than on ip address. What happened? Every time when the UTM resolves a different IP for the specific DNS Host like before, all users related to that profile were "killed" (with the same Log entries like you) to get pushed the new routes. 

Be sure that wasn't find easy,  I've needed almost 2 days to find at...

Long story short: be sure that you have static Network entries only in the VPN profiles! Check if your used DNS-hosts have more than one possible IP (f.eg. by using the command host example.com on a linux box)! That could save lots of time! :)

Best,

Markus

Hallo Markus,

Interesting.  I don't see any way to address the situation where there are changing IPs for a DNS Host used in an SSL VPN Profile except including all of the possible IPs with a Network or a Group object.

Cheers - Bob

Hi Bob,

It was simply a mistake to add one dns-host which is pointing to multiple IPs (RoundRobin). Typical use cases are f.eg.  load balancer DNS entries

I only want to share that because other people should run into that mistake too.

It's important to use static entries in VPN profiles  only. In my case I had to add all IPs (in whatever flavor) recurring this dns entry.

Cheers,

Hey all,

The same issue occurred for us shortly after adding DNS hosts into the allowed networks section.  I noticed that the resolution for certain domains would update at random intervals which kicked off all clients to download the new routing information.  It's a simple fix, just remove the DNS host entries and replace will all IP based network objects as you all stated above. 

Is there any way stop all clients from getting booted other than just adding IPs and not using DNS host entries?

Thanks for your help!

Hi and welcome to the UTM Community!

In situations where an FQDN has multiple A-records that don't change (typical in a "load balancing" scenario), one should use a DNS Group definition since a DNS Host definition only resolves to the first A-record found.

Cheers  Bob

Hi Bob,

Thank you for taking the time to answer!  I apologize as I should have been more clear in my question as I used the wrong term.  I actually did use the DNS group definition and not the DNS host definition.  We saw issues when the DNS group definition would update the number IPs it would resolve as this would cause all clients to get booted from the VPN.  I wasn't sure if there was a way to prevent users from being kicked off of the VPN when the DNS group is dynamically updated.

Ahhh - I see now.  You're right, if an IP changes and the DNS Group object is used in a VPN definition, the connection will be reset for the reason you mentioned.

Cheers - Bob