Thread Info
  • State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 6 subscribers
  • Views 6504 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

KoenDooms

We recently introduced a Multi-Factor Authentication solution for our VPN users and this introduced an annoying 'feature', as we call it in the trade, when using the Sophos VPN client.

Apparently randomly, users are disconnected from VPN by the Sophos UTM 9, requiring the users to log back in.

So far I noticed that when that happens, the openvpn log shows that a:

  1. MANAGEMENT: Client connected from /var/run/openvpn_mgmt was issued.
  2. Followed by a single or, worse, a buch of CMD 'kill <username>'.

Those connected to the VPN are kicked off with a 'SIGTERM[soft,] received, client-instance exiting'

I have the impression it does a kill of all users that already have used the MFA solution, every time a new user connects using MFA.

What triggers these kill commands?



This thread was automatically locked due to age.
Parents
  • 0

    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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 0

    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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
No Data
Unfiltered HTML