Sophos Connect: MFA box parameter in .ovpn files?

This field is a provisioning file only field. Why do you not using the provisioning file in the first place? 

I just want to avoid telling our employees that the Sophos provisioning feature is "buggy" and that it is "normal" that after provisioning the connection is directly connecting but fails (because the OTP code has already been used for the provisioning login). Already known bug, but not getting fixed I guess.
So I will tell them to download the config from the VPN Portal (what is also cool) but don't wanna miss the OTP field feature (only usefull way to save the credentials with OTP).

But back to the question:
The firewall "somehow" tells the Connect Client that an MFA field should be displayed (I assume via parameters in the generated .ovpn file).
How can I set this manually? Or tell the client to use it?

The .pro file tells the client to show the extra field, but in the end its still password+otp token combined. 

I am not aware of a way to tell the client using a OVPN file to do that. 

Then the employees will probably have to live with a failed login during provisioning.
Not a great solution, but if there's no other way with OTP and provisioning.

So the issue you described: There are currently two connections, which are made. Are you sure, the OTP Token is still valid, while Connect tries to reconnect? 

First OTP used to login to VPN Portal.

After getting the OVPN File - Now connecting to the Firewall via SSLVPN using the same OTP.

Is the timeframe, when this will happen, under 30 sec and when was the code generated? 
Meaning: The default is 30 sec OTP lifetime. 
The OTP could be already invalid by the time, we try the connect via SSLVPN. 

I could successfully workaround this by using a 90 sec OTP token, which is of course not a valid solution to change OTPs, but it indicates, this issue could be potentially a "works as designed" and not easy to fix. Maybe by increasing the speed of the initial access and the use of OVPN. 

OTPs are not invalid because they are already used. Instead the are invalid due the nature of time. 

I would say it's not the lifetime of the OTP (30 sec. default for me). Can reproduce it every time:

- importing pro file
- waiting for fresh OTP
- 24:42 sec -> config is provided
- 24:46 sec -> login to connection failed

Auth. via AD + OTP for all users.

If the OTP would be still valid (as you see it's just some seconds), there would be no login problem.
When trying again with new OTP I can login again.

Looking into this, do you see access_server.log entries about both sign-ins? 

MESSAGE Mar 22 15:24:03.622485Z [access_server]: tlvserver_process_request: GOT ALERT.EXECUTE_HEARTBEAT
MESSAGE Mar 22 15:24:21.715501Z [CAA]: (CA_keep_alive): access_server heartbeat
MESSAGE Mar 22 15:24:21.715531Z [CAA]: (CA_keep_alive): Next CA batch in 45 seconds
SUCCESS Mar 22 15:24:42.136789Z [access_server]: (check_auth_result): user 'max.mustermann@mydomain.local'(backend) Authenticated with server id '3'
MESSAGE Mar 22 15:24:42.136834Z [OTP_AUTH]: (otp_code_correct): Will verify code 131346 for user max.mustermann@mydomain.local
MESSAGE Mar 22 15:24:42.332239Z [OTP_AUTH]: (otp_handle_short_password_success_request): ACCEPT1 for user max.mustermann@mydomain.local max.mustermann
SUCCESS Mar 22 15:24:42.332270Z [access_server]: (check_auth_result): user 'max.mustermann@mydomain.local'(backend) Authenticated with server id '3'
/_conf/csc/auth_utility update_usergrouprel "{ \"userid\": 7, \"groupid_list\" : [ 6 ] }"
buffer : status 0
MESSAGE Mar 22 15:24:42.351782Z [access_server]: (delete_admin_access_entry): diff = 51, counter = 900
SUCCESS Mar 22 15:24:45.361054Z [access_server]: (check_auth_result): user 'max.mustermann@mydomain.local'(backend) Authenticated with server id '3'
MESSAGE Mar 22 15:24:45.361101Z [OTP_AUTH]: (otp_code_correct): Will verify code 131346 for user max.mustermann@mydomain.local
ERROR Mar 22 15:24:45.365719Z [OTP_AUTH]: (otp_code_correct): User max.mustermann@mydomain.local provided the same OTP code, declining it
MESSAGE Mar 22 15:24:45.365738Z [OTP_AUTH]: (otp_handle_short_password_success_request): REJECT1 for user max.mustermann@mydomain.local (bad OTP code or user's token is not active)
ERROR Mar 22 15:24:45.365762Z [access_server]: check_auth_result: VPN/SSLVPN/MYACC Authentication Failed
MESSAGE Mar 22 15:24:45.365864Z [access_server]: (update_admin_access_table): ## Admin user authentication failed from IP (my public IP)
MESSAGE Mar 22 15:25:03.849332Z [access_server]: tlvserver_process_request: GOT ALERT.EXECUTE_HEARTBEAT
MESSAGE Mar 22 15:25:06.759140Z [CAA]: (CA_keep_alive): access_server heartbeat
MESSAGE Mar 22 15:25:06.759166Z [CAA]: (CA_keep_alive): Next CA batch in 45 seconds
MESSAGE Mar 22 15:25:51.803398Z [CAA]: (CA_keep_alive): access_server heartbeat
MESSAGE Mar 22 15:25:51.803425Z [CAA]: (CA_keep_alive): Next CA batch in 45 seconds
MESSAGE Mar 22 15:26:03.993998Z [access_server]: tlvserver_process_request: GOT ALERT.EXECUTE_HEARTBEAT
MESSAGE Mar 22 15:26:36.848068Z [CAA]: (CA_keep_alive): access_server heartbeat
MESSAGE Mar 22 15:26:36.848097Z [CAA]: (CA_keep_alive): Next CA batch in 45 seconds
MESSAGE Mar 22 15:27:03.554963Z [access_server]: tlvserver_process_request: GOT ALERT.EXECUTE_HEARTBEAT
MESSAGE Mar 22 15:27:21.892916Z [CAA]: (CA_keep_alive): access_server heartbeat
MESSAGE Mar 22 15:27:21.892947Z [CAA]: (CA_keep_alive): Next CA batch in 45 seconds
MESSAGE Mar 22 15:28:03.892539Z [access_server]: tlvserver_process_request: GOT ALERT.EXECUTE_HEARTBEAT
MESSAGE Mar 22 15:28:06.937633Z [CAA]: (CA_keep_alive): access_server heartbeat
MESSAGE Mar 22 15:28:06.937658Z [CAA]: (CA_keep_alive): Next CA batch in 45 seconds
MESSAGE Mar 22 15:28:51.982710Z [CAA]: (CA_keep_alive): access_server heartbeat
MESSAGE Mar 22 15:28:51.982743Z [CAA]: (CA_keep_alive): Next CA batch in 45 seconds

Ah, i remember an KIL entry about this: 

https://docs.sophos.com/support/kil/index.html

I will look into this situation in more detail. 

Thank you for taking a look.
Was hoping the problem would be fixed with v20, unfortunately still there. Especially as it affects all customers who use provisioning with OTP (will probably be quite a few).