Bug 264528 - net/freerdp: NLA fails to connect through gateway after 13.1 upgrade: rdg_process_close_packet:freerdp_set_last_error_ex E_PROXY_INTERNALERROR [0x800759D8]
Summary: net/freerdp: NLA fails to connect through gateway after 13.1 upgrade: rdg_pro...
Status: Closed Feedback Timeout
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords: needs-qa
Depends on:
Blocks: 264030
  Show dependency treegraph
 
Reported: 2022-06-07 22:43 UTC by alt2600
Modified: 2024-05-16 09:58 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (vvd)
koobs: merge-quarterly?


Attachments
connect fail log (9.48 KB, text/plain)
2022-06-07 22:43 UTC, alt2600
no flags Details
pkg info freerdp (1.92 KB, text/plain)
2022-06-08 02:04 UTC, alt2600
no flags Details
pkg version -v (123.83 KB, text/plain)
2022-06-08 02:05 UTC, alt2600
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description alt2600 2022-06-07 22:43:33 UTC
Created attachment 234532 [details]
connect fail log

so after I updated to 13.1 from 13.0 release I ran into this problem. I've attached the log. It connects to the remote gateway, my 2 factor authentication fires which means the gateway accepted my connection, and then when passed on to the host the NLA connection fails. I had a 13.0 bhyve so I built things there, and setup X11 forwarding. Connection works fine with exactly the same command switches as those that failed under 13.1 . I'm not sure if this is a clang issue, and openssl issue or what. But this no longer seems to connect to windows 10 hosts via a remote rdp gateway when using 13.1 amd64



[18:06:02:632] [84063:0f212700] [DEBUG][com.freerdp.core.nego] - RequestedProtocols: 3
[18:06:02:662] [84063:0f212700] [DEBUG][com.freerdp.core.nego] - RDP_NEG_RSP
[18:06:02:662] [84063:0f212700] [DEBUG][com.freerdp.core.nego] - selected_protocol: 2
[18:06:02:662] [84063:0f212700] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_FINAL
[18:06:02:662] [84063:0f212700] [DEBUG][com.freerdp.core.nego] - Negotiated NLA security
[18:06:02:662] [84063:0f212700] [DEBUG][com.freerdp.core.nego] - nego_security_connect with PROTOCOL_HYBRID
[18:06:02:697] [84063:0f212700] [ERROR][com.freerdp.core] - rdg_process_close_packet:freerdp_set_last_error_ex E_PROXY_INTERNALERROR [0x800759D8]
[18:06:02:729] [84063:0f212700] [DEBUG][com.freerdp.core.nego] - Failed to connect with NLA security
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2022-06-07 23:34:19 UTC
@Reporter Could you please provide:

- uname -a output
- pkg version -v output (as attachment)
- pkg info freerdp output (as attachment)
Comment 2 alt2600 2022-06-08 02:04:31 UTC
Created attachment 234536 [details]
pkg info freerdp
Comment 3 alt2600 2022-06-08 02:05:13 UTC
Created attachment 234537 [details]
pkg version -v
Comment 4 alt2600 2022-06-08 02:11:11 UTC
(In reply to Kubilay Kocak from comment #1)

see attached as requested

FreeBSD socrates.nakatomi.com 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212b MRFALCON amd64

DEFAULT_VERSIONS+=ssl=base

uname -a above and anonymized, also forgot to mention I use base ssl. all packages were updated with portmaster from 13.0 to 13.1, my ports tree is current as of

commit 8d737f63df452ba29a088c70e5bc31f947ab8452 (HEAD -> main, origin/main, origin/HEAD)
Author: Yuri Victorovich <yuri@FreeBSD.org>
Date:   Sun Jun 5 13:10:43 2022 -0700

    devel/xbyak: Update 6.06 -> 6.60
    
    Also improve install target.

my 13.0 vm maybe slightly ahead due to syncing slightly after.
Comment 5 Vladimir Druzenko freebsd_committer freebsd_triage 2022-06-08 03:16:58 UTC
I never used proxy in freerdp, so without detailed description can't even check.
What exact commands do you use for reproduce this?
Comment 6 alt2600 2022-06-08 13:04:04 UTC
(In reply to VVD from comment #5)

I run from a shell script that selects different users and hosts but the basic switches are thus to my connect function, the debug one is new for testing do not usually use that, title just ends up being the hostname I'm connecting to. I've tried messing with sec level to no avail. same script running on 13.0 connects to the host no issue.


xfreerdp -clipboard /dynamic-resolution +compression /compression-level:2 /g:remote.nakatomi.com /d:NAKATOMI /u:${2} /v:${1} +auto-reconnect /auto-reconnect-max-retries:5 +async-update /title:${3} /timeout:99999 /log-level:DEBUG
Comment 7 Vladimir Druzenko freebsd_committer freebsd_triage 2022-06-08 15:38:48 UTC
(In reply to alt2600 from comment #6)
How to configure gateway? Never used it before.
Comment 8 alt2600 2022-06-08 22:26:04 UTC
(In reply to VVD from comment #7)


/g:remote.nakatomi.com

sets the windows rdp gateway to use

/d:NAKATOMI 

sets the AD domain

there are no other configuration options for the gateway. I have nothing but defaults set for the security, cert types to allow, etc.
Comment 9 Vladimir Druzenko freebsd_committer freebsd_triage 2022-07-29 12:11:25 UTC
Try to test with version 2.8.0: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265498
Comment 10 alt2600 2022-07-29 21:44:33 UTC
(In reply to VVD from comment #9)

unfortunately no dice, i even tried adding +enforce-tlsv1_2 which seemed to just delay the erroring out


this is just trying out the box with the same settings that work from 13.0 bhyve X!! forwarded to my desktop using the older version of freerdp. I'll take a harder look at the changelog to see if any other options exist, but I have to log into work now so cannot play around. Its has to be something that is different between 13.0 and 13.1 , and beyond openssl in base and clang I don't know what else it could be. 


[16:55:19:583] [44161:0f212700] [DEBUG][com.freerdp.core] - freerdp_connect:freerdp_set_last_error_ex resetting error state
[16:55:19:583] [44161:0f212700] [DEBUG][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
[16:55:19:583] [44161:0f212700] [DEBUG][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
[16:55:19:583] [44161:0f212700] [DEBUG][com.freerdp.channels.drdynvc.client] - VirtualChannelEntryEx
[16:55:19:583] [44161:0f212700] [DEBUG][com.freerdp.client.common.cmdline] - loading channelEx drdynvc
[16:55:19:587] [44161:0f212700] [DEBUG][com.freerdp.primitives] - primitives benchmark result:
[16:55:20:755] [44161:0f212700] [DEBUG][com.freerdp.primitives] -  * generic= 17
[16:55:20:906] [44161:0f212700] [DEBUG][com.freerdp.primitives] -  * optimized= 105
[16:55:20:906] [44161:0f212700] [DEBUG][com.freerdp.primitives] - primitives autodetect, using optimized
[16:55:20:911] [44161:0f212700] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE
[16:55:20:911] [44161:0f212700] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE
[16:55:20:911] [44161:0f212700] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE
[16:55:20:911] [44161:0f212700] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[16:55:20:911] [44161:0f212700] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE
[16:55:20:911] [44161:0f212700] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE
[16:55:20:911] [44161:0f212700] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_NLA
[16:55:20:911] [44161:0f212700] [DEBUG][com.freerdp.core.nego] - Attempting NLA security
[16:55:20:034] [44161:0f212700] [DEBUG][com.freerdp.core] - freerdp_tcp_connect:freerdp_set_last_error_ex resetting error state
[16:55:20:034] [44161:0f212700] [DEBUG][com.freerdp.core] - connecting to peer <redacted>
GatewayPassword: 
[16:55:24:948] [44161:0f212700] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[16:55:24:948] [44161:0f212700] [DEBUG][com.winpr.sspi.NTLM] - change state from NTLM_STATE_INITIAL to NTLM_STATE_INITIAL
[16:55:24:948] [44161:0f212700] [DEBUG][com.winpr.sspi.NTLM] - change state from NTLM_STATE_INITIAL to NTLM_STATE_NEGOTIATE
[16:55:24:948] [44161:0f212700] [DEBUG][com.winpr.sspi.NTLM] - Write flags [0xe20882b7] NTLMSSP_NEGOTIATE_UNICODE|NTLMSSP_NEGOTIATE_OEM|NTLMSSP_REQUEST_TARGET|NTLMSSP_NEGOTIATE_SIGN|NTLMSSP_NEGOTIATE_SEAL|NTLMSSP_NEGOTIATE_LM_KEY|NTLMSSP_NEGOTIATE_NTLM|NTLMSSP_NEGOTIATE_ALWAYS_SIGN|NTLMSSP_NEGOTIATE_EXTENDED_SESSION_SECURITY|NTLMSSP_NEGOTIATE_VERSION|NTLMSSP_NEGOTIATE_128|NTLMSSP_NEGOTIATE_KEY_EXCH
[16:55:24:948] [44161:0f212700] [DEBUG][com.winpr.sspi.NTLM] - change state from NTLM_STATE_NEGOTIATE to NTLM_STATE_CHALLENGE
[16:55:24:981] [44161:0f212700] [DEBUG][com.winpr.sspi.NTLM] - Read flags [0xe2898235] NTLMSSP_NEGOTIATE_UNICODE|NTLMSSP_REQUEST_TARGET|NTLMSSP_NEGOTIATE_SIGN|NTLMSSP_NEGOTIATE_SEAL|NTLMSSP_NEGOTIATE_NTLM|NTLMSSP_NEGOTIATE_ALWAYS_SIGN|NTLMSSP_TARGET_TYPE_DOMAIN|NTLMSSP_NEGOTIATE_EXTENDED_SESSION_SECURITY|NTLMSSP_NEGOTIATE_TARGET_INFO|NTLMSSP_NEGOTIATE_VERSION|NTLMSSP_NEGOTIATE_128|NTLMSSP_NEGOTIATE_KEY_EXCH
[16:55:24:981] [44161:0f212700] [DEBUG][com.winpr.sspi.NTLM] - change state from NTLM_STATE_CHALLENGE to NTLM_STATE_AUTHENTICATE
[16:55:24:981] [44161:0f212700] [DEBUG][com.winpr.sspi.NTLM] - Write flags [0xe288b235] NTLMSSP_NEGOTIATE_UNICODE|NTLMSSP_REQUEST_TARGET|NTLMSSP_NEGOTIATE_SIGN|NTLMSSP_NEGOTIATE_SEAL|NTLMSSP_NEGOTIATE_NTLM|NTLMSSP_NEGOTIATE_DOMAIN_SUPPLIED|NTLMSSP_NEGOTIATE_WORKSTATION_SUPPLIED|NTLMSSP_NEGOTIATE_ALWAYS_SIGN|NTLMSSP_NEGOTIATE_EXTENDED_SESSION_SECURITY|NTLMSSP_NEGOTIATE_TARGET_INFO|NTLMSSP_NEGOTIATE_VERSION|NTLMSSP_NEGOTIATE_128|NTLMSSP_NEGOTIATE_KEY_EXCH
[16:55:24:981] [44161:0f212700] [DEBUG][com.winpr.sspi.NTLM] - change state from NTLM_STATE_AUTHENTICATE to NTLM_STATE_FINAL
[16:55:24:027] [44161:0f212700] [DEBUG][com.freerdp.core.gateway.rdg] - RDG_OUT_DATA authorization result: 101
[16:55:24:027] [44161:0f212700] [DEBUG][com.freerdp.core.gateway.rdg] - Upgraded to websocket. RDG_IN_DATA not required
[16:55:24:059] [44161:0f212700] [DEBUG][com.freerdp.core.gateway.rdg] - Handshake response received
[16:55:24:059] [44161:0f212700] [DEBUG][com.freerdp.core.gateway.rdg] - errorCode=RPC_S_OK, verMajor=1, verMinor=0, serverVersion=0, extendedAuth=HTTP_EXTENDED_AUTH_SC|HTTP_EXTENDED_AUTH_PAA|HTTP_EXTENDED_AUTH_SSPI_NTLM [0007]
[16:55:24:101] [44161:0f212700] [DEBUG][com.freerdp.core.gateway.rdg] - Tunnel response received
[16:55:24:101] [44161:0f212700] [DEBUG][com.freerdp.core.gateway.rdg] - serverVersion=0, errorCode=RPC_S_OK, fieldsPresent=HTTP_EXTENDED_AUTH_SC|HTTP_EXTENDED_AUTH_PAA|HTTP_EXTENDED_AUTH_SSPI_NTLM [0007]|HTTP_TUNNEL_RESPONSE_FIELD_TUNNEL_ID|HTTP_TUNNEL_RESPONSE_FIELD_CAPS [0003]
[16:55:24:101] [44161:0f212700] [DEBUG][com.freerdp.core.gateway.rdg] - capabilities=HTTP_EXTENDED_AUTH_SC|HTTP_EXTENDED_AUTH_PAA|HTTP_EXTENDED_AUTH_SSPI_NTLM [0007]|HTTP_TUNNEL_RESPONSE_FIELD_TUNNEL_ID|HTTP_TUNNEL_RESPONSE_FIELD_CAPS [0003]|HTTP_CAPABILITY_TYPE_QUAR_SOH|HTTP_CAPABILITY_MESSAGING_CONSENT_SIGN|HTTP_CAPABILITY_MESSAGING_SERVICE_MSG [000d]
[16:55:28:882] [44161:0f212700] [DEBUG][com.freerdp.core.gateway.rdg] - Tunnel authorization received
[16:55:28:883] [44161:0f212700] [DEBUG][com.freerdp.core.gateway.rdg] - errorCode=RPC_S_OK, fieldsPresent=HTTP_EXTENDED_AUTH_SC|HTTP_EXTENDED_AUTH_PAA|HTTP_EXTENDED_AUTH_SSPI_NTLM [0007]|HTTP_TUNNEL_RESPONSE_FIELD_TUNNEL_ID|HTTP_TUNNEL_RESPONSE_FIELD_CAPS [0003]|HTTP_CAPABILITY_TYPE_QUAR_SOH|HTTP_CAPABILITY_MESSAGING_CONSENT_SIGN|HTTP_CAPABILITY_MESSAGING_SERVICE_MSG [000d]|HTTP_TUNNEL_AUTH_RESPONSE_FIELD_REDIR_FLAGS|HTTP_TUNNEL_AUTH_RESPONSE_FIELD_IDLE_TIMEOUT [0003]
[16:55:28:936] [44161:0f212700] [DEBUG][com.freerdp.core.gateway.rdg] - Channel response received
[16:55:28:936] [44161:0f212700] [DEBUG][com.freerdp.core.gateway.rdg] - channel response errorCode=RPC_S_OK, fieldsPresent=HTTP_EXTENDED_AUTH_SC|HTTP_EXTENDED_AUTH_PAA|HTTP_EXTENDED_AUTH_SSPI_NTLM [0007]|HTTP_TUNNEL_RESPONSE_FIELD_TUNNEL_ID|HTTP_TUNNEL_RESPONSE_FIELD_CAPS [0003]|HTTP_CAPABILITY_TYPE_QUAR_SOH|HTTP_CAPABILITY_MESSAGING_CONSENT_SIGN|HTTP_CAPABILITY_MESSAGING_SERVICE_MSG [000d]|HTTP_TUNNEL_AUTH_RESPONSE_FIELD_REDIR_FLAGS|HTTP_TUNNEL_AUTH_RESPONSE_FIELD_IDLE_TIMEOUT [0003]|HTTP_CHANNEL_RESPONSE_FIELD_CHANNELID|HTTP_CHANNEL_RESPONSE_OPTIONAL|HTTP_CHANNEL_RESPONSE_FIELD_UDPPORT [0007]
[16:55:28:936] [44161:0f212700] [DEBUG][com.freerdp.core.nego] - RequestedProtocols: 3
[16:55:28:985] [44161:0f212700] [DEBUG][com.freerdp.core.nego] - RDP_NEG_RSP
[16:55:28:985] [44161:0f212700] [DEBUG][com.freerdp.core.nego] - RDP_NEG_RSP::flags = { [0x1f] |EXTENDED_CLIENT_DATA_SUPPORTED|DYNVC_GFX_PROTOCOL_SUPPORTED|RDP_NEGRSP_RESERVED|RESTRICTED_ADMIN_MODE_SUPPORTED|REDIRECTED_AUTHENTICATION_MODE_SUPPORTED }
[16:55:28:985] [44161:0f212700] [DEBUG][com.freerdp.core.nego] - selected_protocol: 2
[16:55:28:985] [44161:0f212700] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_FINAL
[16:55:28:985] [44161:0f212700] [DEBUG][com.freerdp.core.nego] - Negotiated NLA security
[16:55:28:985] [44161:0f212700] [DEBUG][com.freerdp.core.nego] - nego_security_connect with PROTOCOL_HYBRID
[16:55:28:016] [44161:0f212700] [ERROR][com.freerdp.core] - rdg_process_close_packet:freerdp_set_last_error_ex E_PROXY_INTERNALERROR [0x800759D8]
[16:55:28:052] [44161:0f212700] [DEBUG][com.freerdp.core.nego] - Failed to connect with NLA security
Comment 11 Vladimir Druzenko freebsd_committer freebsd_triage 2022-07-29 22:50:53 UTC
(In reply to alt2600 from comment #10)
Try to create issue in upstream: https://github.com/FreeRDP/FreeRDP/issues
Comment 12 weiss 2022-12-04 10:52:55 UTC
I upgraded FreeBSD from 12.3 to 13.1

FreeBSD latitude-7390.zdv.Uni-Mainz.DE 13.1-RELEASE-p5 FreeBSD 13.1-RELEASE-p5 GENERIC amd64

and freerdp from freerdp-2.8.1 to freerdp-2.8.1 (that is arch changed from 12 to 13). 

freerdp-2.8.1 (arch 12) worked on 12.3.  freerdp-2.8.1 (arch 13) does not work on 13.1 :

[11:49:07:993] [1936:03012700] [ERROR][com.freerdp.core] - rdg_process_close_packet:freerdp_set_last_error_ex E_PROXY_INTERNALERROR [0x800759D8]

I did force install freerdp-2.8.1 (arch 12) on 13.1. Does not work either. Same error.
Comment 13 weiss 2022-12-04 19:59:39 UTC
if you take libssl.so.111 from FreeBSD 12.3, put it in some directory and 
set export LD_LIBRARY_PATH=<to dir>
xfreerdp connects successfully.
Comment 14 Vladimir Druzenko freebsd_committer freebsd_triage 2022-12-11 14:53:57 UTC
(In reply to weiss from comment #13)
openssl version
12.4-p0: OpenSSL 1.1.1q-freebsd  5 Jul 2022
13.1-p5: OpenSSL 1.1.1o-freebsd  3 May 2022

Can you test with libssl.so.111 from FreeBSD 12.4?
Comment 15 weiss 2022-12-18 10:39:42 UTC
libssl.so.111 from FreeBSD 12.4 works as well.
Comment 16 Vladimir Druzenko freebsd_committer freebsd_triage 2022-12-24 14:03:25 UTC
(In reply to weiss from comment #15)

$ freebsd-version 
13.1-RELEASE-p5
$ openssl version
OpenSSL 1.1.1o-freebsd  3 May 2022

$ freebsd-version 
12.4-RELEASE
openssl version
OpenSSL 1.1.1q-freebsd  5 Jul 2022

12.4 have newer version of the OpenSSL.
Look like FreeBSD 13 issue. Maybe build with turned off old algorithms?

Can we add to CC maintainers of the OpenSSL in base?

P.S. BTW, check 2.9.0: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268539
Comment 17 Vladimir Druzenko freebsd_committer freebsd_triage 2022-12-24 14:06:28 UTC
(In reply to alt2600 from comment #10)
> RequestedProtocols: 3
> …
> selected_protocol: 2
Hm…
What values are with lib from 12.4?
Comment 18 weiss 2022-12-28 21:03:12 UTC
They are the same.

[DEBUG][com.freerdp.core.nego] - selected_protocol: 2
[DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_FINAL
[DEBUG][com.freerdp.core.nego] - Negotiated NLA security
[DEBUG][com.freerdp.core.nego] - nego_security_connect with PROTOCOL_HYBRID
[DEBUG][com.freerdp.core.nego] - Failed to connect with NLA security

With libssl from 12.4:

[DEBUG][com.freerdp.core.nego] - selected_protocol: 2
[DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_FINAL
[DEBUG][com.freerdp.core.nego] - Negotiated NLA security
[DEBUG][com.freerdp.core.nego] - nego_security_connect with PROTOCOL_HYBRID
[DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[DEBUG][com.freerdp.core.nla] - nla_client_init 411 : packageName=Negotiate ; cbMaxToken=12256
Comment 19 alt2600 2023-01-04 03:01:38 UTC
(In reply to VVD from comment #17)


Specifically on my 13.0 box that works, with version 2.7.0 when I posted the bug report, I will not upgraded the only thing that allows my connections for remote work, versus 13.1 both report the same. Not even sure it would even build the new ones without fighting ports not necessarily supporting 13.0 anymore, and again, not messing with my money maker.

> RequestedProtocols: 3
> …
> selected_protocol: 2

also, on the 2.9.0 upgrade on my 13.1 box I noticed upstream noted in their repos notes on this patch to 2.9.0 some new options to have freerdp use and internal version of the hmac hashes for md4 and md5 which are needed by rdp but maybe no longer enabled in our openssl because they are cracked algorithms. WITH_INTERNAL_MD5 and WITH_INTERNAL_MD4 cmake variables in the winpr sub-project cmake files in WRKSRC. I would post the patch that enabled them as options, but despite confirming they were seen in the CMakeCache.txt for the BUILD dir, they made no seeming difference. I got the same failed connection message about internal error when I tried to use that version. I had hoped for the Christmas Miracle the day ahead of some remote work being allowed for the holidays, but it woudn't connect. I did notice that we seem to be enabling WITH_MBEDTLS but that gets disabled when using openssl which is also enabled in the CMAKEARGS, similarly WITH_OPENSLES

per configure:
-- Finding required feature OpenSSL for cryptography (encryption, certificate validation, hashing functions)
-- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so (found version "1.1.1o") 
-- Skipping optional feature MbedTLS for cryptography (encryption, certificate validation, hashing functions)
--     Enable feature MbedTLS using "-DWITH_MBEDTLS=ON"
-- Skipping optional feature OpenSLES for multimedia (OpenSLES audio / video)
--     Enable feature OpenSLES using "-DWITH_OPENSLES=ON"

note sure on the MBEDTLS or why it wouldn't be used, but i do have it installed, but I do not have opensles seemingly installed so maybe cmake isnt finding those libraries when built in the wild? Not sure what they do exactly, but they are in the default CMAKEARGS for the port to be turned on. I just assume this needs basic openssl, but after going back to the office basic full time excepting the holidays, I haven't put a lot into testing this much more except when I see the new releases in ports.

### attempted use patch I don't know it would be good to attach because it didn't work so I put it inline here. Ignore the bits on OS version checking, and the bits where it took way to much effort for me to make CMake add the option to the cache and process its use in the project, reasons to clean the patch up before I attach too. I had sought to make it auto enable the option if it was a 13.1 system or newer, but that code never worked so I left them as knobs, which seemed to not help the situation out in my case. Not sure they matter as the 2.7.0 version in the old ports tree on my RDP connection VM has the same message in configure of not actually using them, or maybe no specific pieces of those. I only mention since this is loosly connected to ssl, so maybe no issue at all. Did not try turning off OpenSSL leaving those set, and trying the internal md4 & md5 methods that do the hmac algorithm for them as needed by rdp protocol. 

diff --git a/net/freerdp/Makefile b/net/freerdp/Makefile
index 8481edcbc6f1..c606e485c0f7 100644
--- a/net/freerdp/Makefile
+++ b/net/freerdp/Makefile
@@ -37,7 +37,7 @@ PLIST_SUB+=	PATCHVERSION="${PATCHVERSION}"
 PLIST_SUB+=	MAJORVERSION="${MAJORVERSION}"
 
 OPTIONS_DEFINE=		ALSA BROKENFOCUS CUPS FAAC FAAD FFMPEG GSM GSTREAMER \
-			ICU JPEG KERBEROS LAME MANPAGES OPENH264 PCSC \
+			ICU INTERNALMD4 INTERNALMD5 JPEG KERBEROS LAME MANPAGES OPENH264 PCSC \
 			PULSEAUDIO SOXR WAYLAND X11
 OPTIONS_DEFAULT=	CUPS GSTREAMER ICU KERBEROS MANPAGES SWSCALE WAYLAND X11
 OPTIONS_RADIO=		SCALE
@@ -84,6 +84,19 @@ GSTREAMER_LIB_DEPENDS=	libgstbase-1.0.so:multimedia/gstreamer1
 ICU_LIB_DEPENDS=	libicuuc.so:devel/icu
 ICU_CMAKE_BOOL=		WITH_ICU
 
+INTERNALMD4_DESC=		Use Internal MD4 hashes instead of OpenSSL
+#INTERNALMD4_CMAKE_ON=	WITH_INTERNAL_MD4
+INTERNALMD4_CMAKE_BOOL=	WITH_INTERNAL_MD4
+#INTERNALMD4_CONFIGURE_ENV+=	WITH_INTERNAL_MD4
+#INTERNALMD4_CMAKE_ARGS+=	-D WITH_INTERNAL_MD4:BOOL=ON
+
+INTERNALMD5_DESC=		Use Internal MD5 hashes instead of OpenSSL
+#INTERNALMD5_CMAKE_ON=	-DWITH_INTERNAL_MD5:BOOL=ON
+INTERNALMD5_CMAKE_BOOL=	WITH_INTERNAL_MD5
+#INTERNALMD5_CONFIGURE_ENV+=	WITH_INTERNAL_MD5
+#INTERNALMD5_CMAKE_ARGS+=	-D WITH_INTERNAL_MD5:BOOL=ON
+#INTERNALMD5_CMAKE_ARGS+=	-UWITH_INTERNAL_MD5 -DWITH_INTERNAL_MD5:BOOL=ON
+
 JPEG_USES=		jpeg
 JPEG_CMAKE_BOOL=	WITH_JPEG
 
@@ -141,6 +154,19 @@ X11_CMAKE_OFF=		-DWITH_X11:BOOL=OFF -DWITH_XKBFILE:BOOL=OFF
 X11_USES=		xorg
 X11_USE=		xorg=x11,xcursor,xext,xorgproto,xfixes,xi,xinerama,xkbfile,xrandr,xrender,xv
 
+# Detect freebsd 1301000 and autoenable INTERNALMD4 and INTERNALMD5 for gateway support
+# Work around rdp using bad legacy hash algorithms and OpenSSL not enabling them on >13.1
+#.include <bsd.port.options.mk>
+#.if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1301000
+#.if empty(PORT_OPTIONS:MINTERNALMD4) && empty(PORT_OPTIONS:MINTERNALMD5)
+#BROKEN=         NLS support requires QT4 frontend. Run 'make config' again!
+#.endif
+#OPTIONS_SET+=	INTERNALMD4 INTERNALMD5
+#INTERNALMD4= ON
+#INTERNALMD5= ON
+#.endif
+
+
 post-patch:
 	@${REINPLACE_CMD} -e 's|gsm/gsm.h|gsm.h|' \
 		${WRKSRC}/cmake/FindGSM.cmake \
@@ -150,4 +176,5 @@ pre-configure:
 	${CP} ${FILESDIR}/mntent.h ${WRKSRC}/rdtk/include
 	${CP} ${FILESDIR}/mntent_compat.c ${WRKSRC}/channels/rdpdr/client
 
+
 .include <bsd.port.mk>
Comment 20 Vladimir Druzenko freebsd_committer freebsd_triage 2023-09-17 19:10:02 UTC
Is it still issue on 13.2 and with freerdp 2.11.1?
Comment 21 alt2600 2023-09-22 00:05:23 UTC
(In reply to Vladimir Druzenko from comment #20)

it still is not able to connect through an rdp gateway. my password is accepted, 2factor authentication is triggered, and as soon as it is approved the connection drops with an internal error. wish debugging had more context as to what this internal error was in the logs. The old bhyve terminal client version I have still connects fine to the same machines and gateways.

13.0p11 
freerdp v 2.7.0
Comment 22 Vladimir Druzenko freebsd_committer freebsd_triage 2024-01-15 05:41:01 UTC
(In reply to alt2600 from comment #19)
Can you try net/freerdp3 build with WITH_INTERNAL_MD4 WITH_INTERNAL_MD5 WITH_INTERNAL_RC4 in CMAKE_ON=?