Enhancements pertaining to RDM handling VPN connectivity issues

Howdy!

I would like to see some changes to the:

1. "After Execute Wait" section, as follows:
   1. Have a 'failure' condition that will prevent subsequent processing if the requirement is not met within the timeout
   2. Allow for some basic wildcards on the requirement specification because Forticlient just does whatever it wants with adapter names
   3. Allow for the specification of the expected subnet for the IP
2. Remote Session handling section, as follows:
   1. An option for a less obtrusive connection failure message

RE: #1a - Failure Condition Checking
Currently, with the "After Execute Wait" setting on a Forticlient VPN Entry, when set like this:

It does wait either 15 seconds, or for an IP on the adapter, whichever is soonest...
However, after it times out, it just proceeds to mark the VPN entry in RDM as 'Open' anyway, regardless of whether the actual underlying VPN has connected.

What I would like to be able to do is say "If you wait X seconds and there's still no IP on the adapter, the VPN connection attempt has actually failed and the entry should remain 'Closed'.".

What makes matters worse is...
If I have misconfigured the VPN settings, or the internet is temporarily down, or there's a DNS problem, or whatever the scenario is that causes the VPN to not connect at all (rather than just not in time for the timeout).
Not only does the VPN entry go 'Green' anyway, any RDP sessions that I have 'opened' which have triggered the dependent VPN connection to be attempted to begin with, will ALSO then try to open, even though there's not *actually* a connected VPN, and so they naturally fail to connect one by one.

In that scenario, what I would like instead to happen, is for the timeout being reached to indicate that "Hey, no go on the VPN, cancel the VPN connection and leave the VPN entry 'closed', and also cancel the pending list of Session Opens".
I understand that non-Forticlient VPNs can make multiple concurrent connections, so perhaps a "cancel any pending session opens if their VPN settings are configured to link to the VPN entry that has just failed to open" would be appropriate, rather than all of them.

Either that, or the first behaviour of "Oh, no go, guess I'll stop doing the thing", also be applied to the check for VPN at the remote connection session (eg: RDP) entry level, ie:

Though in that scenario, if I'm opening a handful of sessions, it'd still probably attempt the VPN connection for each one, rather than giving me a single message saying "Ope, dependency failed, you should go look into that" and stopping, which is potentially sub-optimal if the error message is obtrusive enough.

For the VPN level, I'd be equally happy if either the current 'wait' process would be changed to make a timeout reflect a failure (as that was my natural assumption), or for an extra checkbox saying 'timeout means failure' or something to be added (to preserve existing workflows), perhaps after the 'Then delay' saying 'Or fail [X]'.

For the 'Remote Session' level, I'd be happiest for the VPN failing to propagate back to the pending Remote Session connections whose linked VPN is the one that failed. Second preference would be a setting on the 'VPN' part that says "If linked VPN fails (or even perhaps 'has failed in the past X seconds'), don't proceed with Opening the session", or failing that, for the "After Execute Wait" component to be able to decide to fail after the adapter IP timeout, like the VPN does, rather than trying to connect anyway.

RE: #1b - Adapter name wildcards
Forticlient for reasons best known to... Someone... Does not pick an adapter and stick to it.
It started off a couple of weeks ago as `Fortinet SSL VPN Virtual Ethernet Adapter (Ethernet 3)`.
However at the moment it's gone to `Fortinet SSL VPN Virtual Ethernet Adapter #2 (Ethernet 5)`.
What made it decide to do this, I do not know. Nor do I have any reason to assume it's finished changing its mind either.

What I'd like to be able to do is say "Okay RDM, we can't trust Forticlient to behave itself... What I'd like you to do is monitor all of the adapters whose name matches the pattern `Fortinet SSL VPN*`, rather than a specific interface, and proceed if an adapter matches, and timeout if no adapter matches.
There's unfortunately no telling which it'll decide to use, and I don't want to have to keep coming back here and reconfiguring you when it changes its mind".

RE: #1c - Specifying the expected subnet
Our infrastructure provider is providing our various development and testing environments as separate Forticlient VPN's.
They are using DHCP to allocate VPN connections an address from a predictable subnet (probably both a typical and sensible arrangement).
The problem is that they all use Forticlient, so if I tell the DEV VPN to wait for an IP on the Forticlient adapter, and the TST VPN is already live and connected... It sees absolutely no problem with assuming therefore that the DEV VPN is connected because the adapter has an IP on it.

What I'd like to be able to do is say "Wait for IP matching mask "192.168.1.0/32" or "192.168.1.*" or something for DEV, and then similarly "Wait for IP matching mask "192.168.2.0/32" or "192.168.2.*" or something for TST.
That way, in combination with the above suggestions, if I attempt to open a connection to three particular DEV RDP sessions, while TST is connected (and I can't figure out a way to pleasantly terminate the TST VPN and it's sessions via the DEV VPN connection attempt, see this forum thread for more details), it'll instead go "Could not connect to DEV VPN" and then "Could not connect to DEV RDP 1" (and then 2 and then 3, or ideally "Could not connect to DEV VPN, aborting connection attempts to sessions depending on DEV VPN" so it doesn't even try it in the first place).

RE: #2d - Less obtrusive failure message
Currently when an RDP session (and perhaps other types of session) fails to reconnect, a pop-up is displayed that inhibits subsequent processing in RDM, so if I determine that I need to open 10 RDP sessions to various instances of a web server, and the underlying VPN connection fails (or succeeds, but to the wrong VPN because I've misconfigured it), I'll get my 10 RDP sessions attempting to connect anyway, and as each one fails, I'll need to click 'Close' before RDM will continue allowing the others to try and fail to connect, ie:


What would be nice instead, is if there were a less aggressive connection attempt failure notification methodology that could be selected for Remote Session entries, where instead of a blocking popup, it just unobtrusively blips up like the windows notifications.
I've seen RDM use some less obtrusive popups in other areas that would be perfect for this sort of 'soft' reconnection failure, like this:


I have found this setting:

Which is great in that it suppresses the obtrusive popup, but it just closes the window without *any* feedback to say why (ie: Invalid credential, can't find host, etc).



Cheers for listening, I love how much RDM already allows me to automate away some of the more tedious parts of my RDP session juggling, y'all have done a truly fantastic job!