RDP connection loss with Sophos Connect

1. This didn't occur while using the "old" open-VPN-Client??

2. try to disable Port 3389 UDP, so RDP has to stay with TCP 3389 -- may be detected as "UDP-Flood"

I have the exact same Problem with a customer but we are using V19 and the new Connect Client 2.2

When I connect with the "old" VPN-Client this also occurs but less frequent.

We do not have any UDP-Flood set up on our Firewall so there should not be a problem with that right?

What can I do to fix this issue?

Do you tried to disable UDP 3389 already?

... may help but got no feedback before.

You could try to disable Firewall Acceleration and/or ipsec acceleration. Or update to V19.5 GA. 

Upgraded firmware current, 19.5, Sophos verified this is not UDP flood, disabled firewall acceleration, provided Wireshark captures during disconnects, and a pcap capture on the firewall side that has been provided to Sophos support.  

Yesterday, I was asked to (by Sophos Support)

1. Disable Firewall acceleration (again)

2. Run command          set vpn conn-remove-tunnel-up disable

Because I have IPSEC tunnels up with another hospital for after hours support, I asked for clarification on what the command actually does.  My reply was to try it "after hours" in case there is an impact.

The ticket is now with our account rep.

Thx

The command you are listing above is per default disabled in newer installations. You find more information here: https://docs.sophos.com/releasenotes/index.html?productGroupID=nsg&productID=xg&versionID=19.0

Disabling 3389 UDP is not because a flood-event.

you may try it ... or not.

per Sophos support, the UDP Flood issue is not the cause.    We have tried disabling firewall acceleration, as well as the command i stated above (and below)

 set vpn conn-remove-tunnel-up disable

No luck as of today, still ongoing, so well over 2 months now, no resolution.  I have our Account Exec and another engineer involved at this point.

I am now being asked to create a test user for Sophos Support (guessing to collect client logs) - we could have done this months ago unfortunately.

I have provided wire shark captures with days/times of disconnects, and they have the logs from the firewall, so we shall see.

Thx

Hello Deresk,

Just to confirm the Case ID you have for this is 05837573?

Regards,

Yes, that is the CASE ID.  Thanks.

Hello Derek,

Thank you for the Case ID. 

I have emailed the manager of the engineers involved in this case and our Escalation Manager. 

As it’s the end of the day for you, most likely you’ll have an email in your mailbox or a call first thing in the morning.

Regards,

as already sayed ... not UDP flood was the problem within my environment ... the first UDP3389 packet kill the session.
one single packet is not really a flood (and flood count stay at zero)

as already sayed ... not UDP flood was the problem within my environment ... the first UDP3389 packet kill the session.
one single packet is not really a flood (and flood count stay at zero)