Microsoft RDP client encryption errors

[glenp42]

Hi,

Since a recent upgrade of Lulu to 2.5.1 I get encryption errors with MicroSoft Remote Desktop client breaking to different hosts with the same error message:

Your Session was disconnected Your session ended because of a data encryption error. If this kleeps happening, contact yoour network administrator for assistance. Error code: 0x407

As I mentioned before, this same message occurs with several RDP hosts and only stopped when I set Lulu DISABLED. I've tried differeing versions of the MS RDP Client (beta as well) with the same result. I've tried various settings in the client with no success. It was not until I disabled Lulu that I had a RDP session last a full day again.

RoyalTSX is better (FreeDRP) and doesn't crash, but it does get disconnect/reconnect blips during a session.

Platform is MacBookPro M2 16GB RAM

Any ideas?

[frakman1]

For what it's worth, I have Lulu 2.5.1 running on MacOS 13.6.2 and it seems to work fine for RDP 10.9.4(2161) I have an allow everything rule for RDP:

My Windows PCs are all Win 10

[hosh0815]

for now (since I read your entry here 4 hours ago) I can confirm, that since LuLu is deaktivated there are no 0x407 errors. And I had the rule like frakman1 to allow RDP. I hope it keep the reason for me...

[codykrieger]

Confirmed—disabling LuLu fixes this issue for me as well.

I wasn't able to keep an RDP session running for more than a couple hours, tops (and often significantly less than that) without seeing the dreaded “encryption error”, but since disabling LuLu, I've had an RDP session running for over a week with no disconnects.

@objective-see Any thoughts on this?

[mailinglists35]

this affects not only MSRDP, but also ssh and unencrypted vnc:

ssh_dispatch_run_fatal: Connection to 192.168.1.1 port 22: message authentication code incorrect

while realvnc client freezes image

using latest lulu on ventura

[mailinglists35]

@objective-see this is 100% reproductible by multiple people. I am getting it so frequent to the point that I am thinking uninstalling LuLu

Please consider it higher in your priority list.

What can we do to help you debug it? Do you have a debug build we can run? Anything else?

[martinh2011]

Same here. Cannot keep RDP sessions open for more than a couple of hours max. Often they last much less than an hour. Uninstalled Lulu and RDP sessions are stable again. LuLu 2.6.3, Microsoft RDP Client 10.9.8 (2217), macOS 14.5 on an MacBook Pro M3

[objective-see]

hrmm this is strange, as (in theory) if there is an allow rule, or if LuLu is in passive mode it will just respond to the OS's "do you want to allow this?" with a yes/no.

Moreover LuLu is only consulted (by the OS) for new outgoing connections. It doesn't do full packet capture, so (again, in theory), once a connection is established LuLu should be out of the picture.

To help debug, can you pop into the terminal and run: log stream --level debug --predicate="subsystem='com.objective-see.lulu'"

....and then post any relevant issues/errors (there will be lots of irrelevant output).

I'll keep digging on my end too! @mailinglists35 is there a simple way to repo this? (You mentioned SSH?)

Mahalo 🙏🏽

[mailinglists35]

@objective-see thank for the log syntax, will extract it and post on next occurring.

I haven't find a way to actually trigger it, but I can start tcpdump on both the client side (mac) and servers side (linux for ssh connections, windows for rdp sessions) and attach the resulting pcap files.

[mikeyh]

Also seeing this issue with 2.6.3 / Intel 14.6 (23G80) and long running RDP / SSH / SFTP / rsync sessions. It's been painful for a while and never realised it was LuLu until recently. Not an issue with other network filters.

I'm guessing this is an issue during renegotiation or 0-RTT resumption.