Available for support for F5 + MFA

[Daniel Lenski]

On Wed, Aug 4, 2021 at 10:57 AM Antonio Petrelli
<antonio.petrelli at gmail.com> wrote:
>
> Il giorno mer 4 ago 2021 alle ore 19:40 Antonio Petrelli
> <antonio.petrelli at gmail.com> ha scritto:
>
> > > OMG IT WORKED! It seems that the error before happens sometimes, but
> > it happens anyway sometimes because something is wrong server side.
> > Wait a bit, ignore the previous email, in the next one I will post another log.
>
> I have good news and bad news.
> The good news is that I managed to make it work.
> The bad news is that it works only if I connect via original f5vpn,
> disconnect, then launch openconnect.

That's interesting.

>> Probably the culprit is the access token.

My guess is that when the f5vpn executable launches, it sends
additional request(s) to the server to somehow activate/enable the
MRHSession cookie to be used for the VPN tunnel…

> GET /vdesk/get_token_for_sessid.php3 HTTP/1.0
> ... bunch of other headers ...
> Cookie: LastMRH_Session=<4-bytes-hex-encoded>; TIN=66000; MRHSession=<MRHSession-Cookie>; F5_ST=<F5-ST-Cookie>; F5_fullWT=1
>
> Now a resource is going to be opened by f5vpn. The resource is:
>
f5-vpn://<corporate-vpn-host-name>?server=<corporate-vpn-host-name>&resourcename=/Common/SSL_VPN_Portal_Import-<id-variable-part>&resourcetype=network_access&cmd=launch&protocol=https&port=443&sid=nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn&token=<some-hex-encoded-value>&otc=<access-session-token>

Can you confirm that the value of the 'sid' field in the f5-vpn:// URI
precisely matches the value of the MRHSession cookie sent in the
get_token_for_sessid.php3 request seen in the browser login? My
expectation is YES, they should be identical. SID appears to be one of
the many names used inconsistently for this 32-hex-digit value.

> What to do now?

Do a MITM capture of the f5vpn binary, and figure out what request(s)
it sends involving the access-session-token value.

> So here's the log, I hope I edited all the needed things :-D

Looks good. For what it's worth, this log doesn't appear to reveal
anything that we don't already understand. The part that we don't
understand apparently *precedes* the requests and responses shown in
the log.

Thanks for working through this, and sorry for the slow response!
Dan