RDP Connection Dying

shaunmccloud · Wed Sep 08, 2021 11:51 pm

On my RB4001 on RouterOS 7, my RDP connection to my Jumpbox keeps dying. When I had it on 6.48.x, the connection was stable. Any suggestions what might be causing this or what to look at?

SiB · Thu Sep 09, 2021 12:11 am

I use 7.1rc3 and work few h per many RDP sessions... .

Check a connection tab in firewall. Double client at proper connection and show it us.

shaunmccloud · Thu Sep 09, 2021 12:15 am

Here you go

udp.png

tcp.png

SiB · Thu Sep 09, 2021 12:46 am

You have all frags ok.
Your RB works in location when your server rdp is, true ?
Means traffic from internet you DNAT to your RDP machine.

My suggestion is to disable fasttrack, reboot and check again.
When this not help then contact with support because your RDP works but is not stable at ros7.1rc*.

shaunmccloud · Thu Sep 09, 2021 2:40 am

You have all frags ok.
Your RB works in location when your server rdp is, true ?
Means traffic from internet you DNAT to your RDP machine.

My suggestion is to disable fasttrack, reboot and check again.
When this not help then contact with support because your RDP works but is not stable at ros7.1rc*.

Yes, my RB4011 is my home router. You mean fully disable fasttrack on my RB4011 and try again? I can do that, tomorrow. Just funny that it worked on 6.48.

shaunmccloud · Thu Sep 09, 2021 5:15 pm

Just disable fasttrack, issue is still occurring. Would posting my entire config help?

SiB · Thu Sep 09, 2021 6:35 pm

I think better will be write a case directly to MikroTik at help.microtik.com becasue this is only DNAT and this works you at Ros6.
If you want to check this, yes you can share export and I will check.

shaunmccloud · Thu Sep 09, 2021 6:44 pm

I am planning on flattening my network in the future.

# jan/02/2002 09:35:19 by RouterOS 7.1rc3
# software id = NO-NO
#
# model = RB4011iGS+
# serial number = NO
/interface ethernet
set [ find default-name=ether2 ] disabled=yes
set [ find default-name=ether3 ] disabled=yes
set [ find default-name=ether4 ] disabled=yes
set [ find default-name=ether5 ] disabled=yes
set [ find default-name=ether6 ] disabled=yes
set [ find default-name=ether7 ] disabled=yes
set [ find default-name=ether8 ] disabled=yes
set [ find default-name=ether9 ] disabled=yes
set [ find default-name=ether10 ] disabled=yes poe-out=off
/interface vlan
add interface=sfp-sfpplus1 name="Guest Wifi" vlan-id=200
add interface=sfp-sfpplus1 name=IoT vlan-id=10
add interface=sfp-sfpplus1 name=VMs vlan-id=20
add interface=sfp-sfpplus1 name=Wifi vlan-id=7
/interface pppoe-client
add add-default-route=yes disabled=no interface=ether1 name=pppoe-out user=NO
/interface list
add name=WAN
add name=LAN
/interface lte apn
set [ find default=yes ] ip-type=ipv4
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip dhcp-server option
add code=42 name=NTPVMs value="'172.16.20.1'"
add code=42 name=NTPLAN value="'172.16.6.1'"
add code=42 name=NTPIoT value="'172.16.10.1'"
add code=42 name=NTPWifi value="'172.16.7.1'"
add code=42 name="NTPGuest Wifi" value="'172.16.200.1'"
/ip dhcp-server option sets
add name=Wifi options=NTPWifi
add name=LAN options=NTPLAN
add name=VMs options=NTPVMs
add name="Guest Wifi" options="NTPGuest Wifi"
add name=IoT options=NTPIoT
/ip ipsec profile
set [ find default=yes ] dh-group=modp2048 enc-algorithm=aes-128 hash-algorithm=sha256
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256 enc-algorithms=aes-256-gcm,aes-192-ctr,aes-192-gcm,aes-128-gcm lifetime=0s pfs-group=modp2048
/ip pool
add name=IoT_pool ranges=172.16.10.100-172.16.10.254
add name=LAN_pool ranges=172.16.6.100-172.16.6.254
add name="Guest Wifi_pool" ranges=172.16.200.2-172.16.200.254
add name=VMs_pool ranges=172.16.20.100-172.16.20.254
add name=Wifi_pool ranges=172.16.7.100-172.16.7.254
/ip dhcp-server
add address-pool=IoT_pool dhcp-option-set=IoT interface=IoT lease-time=1w name=IoT
add address-pool=LAN_pool dhcp-option-set=LAN interface=sfp-sfpplus1 lease-time=1w name=LAN
add address-pool="Guest Wifi_pool" dhcp-option-set="Guest Wifi" interface="Guest Wifi" lease-time=1w name="Guest Wifi"
add address-pool=VMs_pool dhcp-option-set=VMs interface=VMs lease-time=1w name=VMs
add address-pool=Wifi_pool dhcp-option-set=Wifi interface=Wifi lease-time=1w name=Wifi
/queue simple
add burst-limit=2M/2M burst-threshold=2M/2M burst-time=10s/10s comment="Guest Wifi" limit-at=1M/1M max-limit=1M/1M name="Guest Wifi" priority=6/6 queue=default/default target="Guest Wifi"
/routing bgp template
set default as=65530 disabled=no name=default output.network=bgp-networks
/routing table
add fib name=""
/system logging action
set 3 remote=172.16.6.2
/zerotier
set zt1 comment="ZeroTier Central controller - https://my.zerotier.com/" identity="NO" name=zt1 port=9993
/zerotier interface
add instance=zt1 mac-address=62:8F:2E:C8:F7:2F name=zerotier1 network=NO
/ip neighbor discovery-settings
set discover-interface-list=none
/interface list member
add interface=ether1 list=WAN
add interface=sfp-sfpplus1 list=LAN
add interface="Guest Wifi" list=LAN
add interface=IoT list=LAN
add interface=VMs list=LAN
add interface=Wifi list=LAN
add interface=pppoe-out list=WAN
/ip address
add address=172.16.6.1/24 interface=sfp-sfpplus1 network=172.16.6.0
add address=172.16.7.1/24 interface=Wifi network=172.16.7.0
add address=172.16.10.1/24 interface=IoT network=172.16.10.0
add address=172.16.20.1/24 interface=VMs network=172.16.20.0
add address=172.16.200.1/24 interface="Guest Wifi" network=172.16.200.0
add address=192.168.254.253/24 interface=ether1 network=192.168.254.0
/ip cloud
set ddns-enabled=yes
/ip dhcp-server lease
add address=172.16.6.15 client-id=apc mac-address=00:C0:B7:31:A7:AD
add address=172.16.10.2 client-id=HeidiNightstand mac-address=60:38:E0:F1:C8:71
add address=172.16.10.5 client-id=HueBridge mac-address=00:17:88:A5:42:D9
add address=172.16.7.5 client-id=erx mac-address=04:18:D6:06:18:6F
add address=172.16.7.15 mac-address=70:2C:09:69:FF:88
add address=172.16.10.4 client-id=1:b0:be:76:46:b9:92 mac-address=B0:BE:76:46:B9:92 server=IoT
add address=172.16.7.4 client-id=1:44:90:bb:5:c0:cd mac-address=44:90:BB:05:C0:CD server=Wifi
add address=172.16.10.3 client-id=1:2c:aa:8e:d6:93:4c mac-address=2C:AA:8E:D6:93:4C server=IoT
add address=172.16.7.3 client-id=1:dc:52:85:d4:15:9f mac-address=DC:52:85:D4:15:9F server=Wifi
add address=172.16.20.3 client-id=1:52:54:0:c8:d0:49 mac-address=52:54:00:C8:D0:49 server=VMs
add address=172.16.20.4 client-id=1:52:54:0:be:8c:1c mac-address=52:54:00:BE:8C:1C server=VMs
/ip dhcp-server network
add address=172.16.6.0/24 dns-server=172.16.6.1 domain=mccloud.lan gateway=172.16.6.1 netmask=24
add address=172.16.7.0/24 dns-server=172.16.7.1 domain=mccloud.lan gateway=172.16.7.1
add address=172.16.10.0/24 dns-server=172.16.10.1 domain=mccloud.lan gateway=172.16.10.1
add address=172.16.20.0/24 dns-server=172.16.20.1 domain=mccloud.lan gateway=172.16.20.1
add address=172.16.200.0/24 dns-server=172.16.200.1 domain=mccloud.lan gateway=172.16.200.1
/ip dns
set allow-remote-requests=yes servers=1.1.1.1,1.0.0.1
/ip dns static
add address=172.16.6.2 name=transmission.smccloud.com
add address=172.16.6.2 name=unimus.smccloud.com
add address=172.16.6.2 name=airsonic.smccloud.com
add address=172.16.6.2 name=home.smccloud.com
add address=172.16.6.2 name=jackett.smccloud.com
add address=172.16.20.3 name=jenkins.smccloud.com
add address=172.16.6.2 name=lidarr.smccloud.com
add address=172.16.6.2 name=nzbget.smccloud.com
add address=172.16.6.2 name=omada.smccloud.com
add address=172.16.6.2 name=ombi.smccloud.com
add address=172.16.6.2 name=paperless.smccloud.com
add address=172.16.6.2 name=piwigo.smccloud.com
add address=172.16.6.2 name=plex.smccloud.com
add address=172.16.6.2 name=radarr.smccloud.com
add address=172.16.6.2 name=sonarr.smccloud.com
add address=172.16.6.2 name=speedtest.smccloud.com
add address=172.16.6.2 name=subversion.smccloud.com
add address=172.16.6.2 name=syncthing.smccloud.com
add address=172.16.6.2 name=tautulli.smccloud.com
add address=172.16.6.2 name=tdarr.smccloud.com
add address=172.16.20.3 name=jumpbox
add address=172.16.6.2 name=bb-8
add address=172.16.20.3 name=jumpbox.mccloud.lan
add address=172.16.6.2 name=bb-8.mccloud.lan
/ip firewall filter
add action=fasttrack-connection chain=forward connection-mark=!ipsec connection-state=established,related hw-offload=yes
add action=accept chain=forward connection-state=established,related,untracked
add action=fasttrack-connection chain=input connection-mark=!ipsec connection-state=established,related hw-offload=yes
add action=accept chain=input connection-state=established,related,untracked
add action=fasttrack-connection chain=output connection-mark=!ipsec connection-state=established,related hw-offload=yes
add action=accept chain=output connection-state=established,related,untracked
add action=accept chain=input connection-state=established,related
add action=drop chain=input connection-state=invalid
add action=accept chain=input in-interface=pppoe-out protocol=icmp
add action=drop chain=input in-interface=pppoe-out
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-mark=!ipsec connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=forward in-interface="Guest Wifi" out-interface=IoT
add action=drop chain=forward in-interface="Guest Wifi" out-interface=VMs
add action=drop chain=forward in-interface="Guest Wifi" out-interface=Wifi
add action=drop chain=forward in-interface="Guest Wifi" out-interface=sfp-sfpplus1
add action=drop chain=forward in-interface=IoT out-interface="Guest Wifi"
add action=drop chain=forward in-interface=VMs out-interface="Guest Wifi"
add action=drop chain=forward in-interface=Wifi out-interface="Guest Wifi"
add action=drop chain=forward in-interface=sfp-sfpplus1 out-interface="Guest Wifi"
/ip firewall nat
add action=dst-nat chain=dstnat comment=SSH in-interface=pppoe-out port=NO protocol=tcp to-addresses=172.16.6.2 to-ports=NO
add action=dst-nat chain=dstnat comment=HTTP in-interface=pppoe-out port=NO protocol=tcp to-addresses=172.16.6.2 to-ports=NO
add action=dst-nat chain=dstnat comment=HTTPS in-interface=pppoe-out port=NO protocol=tcp to-addresses=172.16.6.2 to-ports=NO
add action=dst-nat chain=dstnat comment=RDP in-interface=pppoe-out port=NO protocol=tcp to-addresses=172.16.20.3 to-ports=NO
add action=dst-nat chain=dstnat comment=RDP in-interface=pppoe-out port=NO protocol=udp to-addresses=172.16.20.3 to-ports=NO
add action=dst-nat chain=dstnat comment=Plex in-interface=pppoe-out port=NO protocol=tcp to-addresses=172.16.6.2 to-ports=NO
add action=dst-nat chain=dstnat comment=Syncthing in-interface=pppoe-out port=NO protocol=tcp to-addresses=172.16.6.2 to-ports=NO
add action=dst-nat chain=dstnat comment=Syncthing port=NO protocol=udp to-addresses=172.16.6.2 to-ports=NO
add action=dst-nat chain=dstnat comment=Transmission dst-address=172.16.6.2 in-interface=pppoe-out port=NO protocol=tcp to-addresses=172.16.6.2 to-ports=NO
add action=dst-nat chain=dstnat comment=Transmission dst-address=172.16.6.2 in-interface=pppoe-out port=NO protocol=udp to-addresses=172.16.6.2 to-ports=NO
add action=dst-nat chain=dstnat comment="Resilio Sync" in-interface=pppoe-out port=NO protocol=tcp to-addresses=172.16.6.2 to-ports=NO
add action=dst-nat chain=dstnat comment="Resilio Sync" in-interface=pppoe-out port=NO protocol=tcp to-addresses=172.16.6.2 to-ports=NO
add action=dst-nat chain=dstnat comment="Resilio Sync" in-interface=pppoe-out port=NO protocol=udp to-addresses=172.16.6.2 to-ports=NO
add action=masquerade chain=srcnat comment="nat to modem" dst-address=192.168.254.254 out-interface=ether1
add action=masquerade chain=srcnat comment=Masquerade out-interface-list=WAN
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set www-ssl certificate=router disabled=no tls-version=only-1.2
set api disabled=yes
set api-ssl certificate=router tls-version=only-1.2
/ip ssh
set strong-crypto=yes
/ipv6 nd
set [ find default=yes ] advertise-dns=no
/snmp
set contact=smccloud@smccloud.com enabled=yes location="Mechanical  Room"
/system clock
set time-zone-name=America/Chicago
/system identity
set name=RB4011iGS+RM
/system logging
add action=remote topics=critical
add action=remote topics=error
add action=remote topics=info
add action=remote topics=warning
/system ntp client
set enabled=yes mode=multicast
/system ntp server
set enabled=yes manycast=yes multicast=yes
/system ntp client servers
add address=128.101.101.101
add address=134.84.84.84
/system package update
set channel=development
/system resource irq rps
set sfp-sfpplus1 disabled=no
/tool bandwidth-server
set authenticate=no enabled=no
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=none
/tool mac-server ping
set enabled=no

nescafe2002 · Thu Sep 09, 2021 6:51 pm

I must say that I've had the same problem since upgrading my RB4011 to v7.1rc1.

Mostly connections to Windows 2012 R2 servers. They are probably really sensitive to interrupted data streams.

I am using direct RDP, TCP+UDP, over IPSEC.

shaunmccloud · Thu Sep 09, 2021 6:53 pm

I must say that I've had the same problem since upgrading my RB4011 to v7.1rc1.

Mostly connections to Windows 2012 R2 servers. They are probably really sensitive to interrupted data streams.

I am using direct RDP, TCP+UDP, over IPSEC.

And mine is a 2012 R2 server.

SiB · Thu Sep 09, 2021 8:23 pm

Only strange stuff at your config is just fastrack at all chains, means with input & output.
If I can suggest you then please add some rule dedicated to accept DNATed traffic, I not like that default rule know as "defconf: drop all from WAN not DSTNATed"

/ip firewall filter
add action=accept chain=forward comment="all from WAN DSTNATed" connection-nat-state=dstnat connection-state=new in-interface-list=WAN

rplant · Fri Sep 10, 2021 6:15 am

Hi,

Perhaps block the UDP, and see if that helps (or not).
(Give Mikrotik something more targeted to look at)

nescafe2002 · Fri Sep 24, 2021 11:06 pm

I have examined logs and traces but could not find a cause for this issue.. unfortunately RDP is extremely sensitive and will initiate a TCP RST as soon as 'something' is off.. disconnecting after 5 to 15 seconds, leaving these unhelpful events in the log (Event Viewer/Application and Services Logs/Microsoft/Windows/TerminalServices-LocalSessionManager/Operational):

Session 5 has been disconnected, reason code 0

This occurs with multiple servers, over ipsec, from the same client.

Downgraded the router from v7.1rc4 to v6.49rc1, RDP connections are rock solid.

shaunmccloud · Fri Sep 24, 2021 11:15 pm

My fix was to upgrade to Server 2019. But not everyone has that option.

admin360 · Wed Dec 08, 2021 4:25 pm

Same problem. I updated the router to 7.1 today. RDP to the server with Windows Server 2012 disconnects for 1 sec.
Downgraded firmware to 6.49.2 - no problems seen.

Mysterio · Wed Dec 15, 2021 8:25 am

Hi ! After replacing 4011 to 5009 got the same problem. When connecting via RDP to WS2012R2, the connection is disconnected every 30-40 seconds (approximately) and is restored after 5 seconds. In the Connection tracker, connection tcp state in an "established" position, then changes to the "close", and after 5 seconds it disappears and a new one opens immediately, with other NAT ports. I dont know how to solve this problem.

sychra · Tue Dec 21, 2021 12:10 am

I have the same problem with RDP on Windows Server 2012 R2. I managed to force the end the cyclic disconnection by reducing the MTU from 1500 to 1492. I reported a problem with version 7.x and RDP to technical support. I think he doesn't believe me, than this problem exist. Also write to them, if there are more of us, they may believe.

SimeTom · Tue Dec 28, 2021 5:55 pm

I'm experiencing the same after upgrading from RouterOS 6.49 to 7.1.1.
RDP connection is slow to establish and is dropping after 5-20 seconds. RouterOS 7 is on my side from where i connect to different servers. Most of the servers works just fine, but some don't.

poirus · Thu Dec 30, 2021 2:45 pm

Same for me. Different devices (4011, 3011, 1009, 2004) and can't find where is the promble after upgrade to ROS7. The only one solution is to disable UDP for RDP client. Win 2012R2, Win 2016 and win 2019 all gives me a disconnect after 20-60 sec.
And as yours for me everything was good on ROS6, but we are living in 2021, OVPN over tcp is to slow.

SiB · Mon Jan 03, 2022 12:05 pm

I am planning on flattening my network in the future.

# jan/02/2002 09:35:19 by RouterOS 7.1rc3
/ip firewall filter
...
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
...

Hmm, I update more and more RB to 7.1.1 and not have problem with RDP.. but many ppl report here problem.
Maybe it's because my DNAT'a are just accepted as
ip firewall/filter/add connection-nat-state=dstnat action=accept comment="DNAT Accept"
and just one big DENY below.
I not see errors in that config.
Please write to official support.

@ALL Please take your supout.rif and send it to support as "RDP Broke" and support channels are at help.mikrotik.com

rafalgit · Mon Jan 10, 2022 4:35 pm

I think i nail it.

I has the same problem with serwer 2012r2 and RoS 7.1.0
I hear complain about that in eariel version but I do not get arout to solve it.

When wireguarding I fount that strange communication:

wireguard test forward: in:Lan out:wireguardADM, src-mac X, proto UDP, server2012r2:3389->CLIENT_RDP:61792, len 40

in every 15 seconds.

In connection traking I increase UDP timeout to 20 second and problem go away.

In IPsec connection I do not see any dropping packet.

i file ticket about that #SUP-70818

atnet1 · Mon Jan 10, 2022 5:41 pm

After upgrading to 7.1.1, I also have disconnections exactly every minute with the Windows server 2012 only. The rules above don't help.

rafalgit · Mon Jan 10, 2022 11:45 pm

hi

I must miss led you I pass my log its not a rule

if you want some code to paste in termilal try this:

ip/firewall/connection/tracking/set udp-timeout=20s

windows reconnect exactly 75 seconds apart. After five try's every 15s apart.

atnet1 · Tue Jan 11, 2022 8:39 am

hi

I must miss led you I pass my log its not a rule
if you want some code to paste in termilal try this:
Code: Select all
ip/firewall/connection/tracking/set udp-timeout=20s
windows reconnect exactly 75 seconds apart. After five try's every 15s apart.

Thanks ! It works !

nescafe2002 · Tue Jan 11, 2022 11:23 pm

Thank you. Increasing the udp timeout fixes the issue. Looks like v7 does not detect properly udp streams.

3nginizer · Sun Jan 30, 2022 1:01 pm

This issue still persists in long term 7.1
I hope it gets the development team's attention to fix it soon

Kraken2k · Wed Mar 09, 2022 6:20 pm

I can confirm this issue is present in v7.1.2 too.

Also confirm, that Increasing the UDP time limit in Connections Tracking as suggested above, solves the problem.

Thanks, rafalgit!

PavelUher · Mon Aug 08, 2022 6:46 pm

Same problem here, same solution:

Site A: CCR2116 with ROS 7.1.2
Site B: RB4011 with ROS 7.2.1

Symptoms: Unstable RDP connection to off-site Windows Server 2012 R2 in TCP+UDP mode. RDP Connection breaks every 60-90 seconds.
Problem successfully fixed by increasing UDP timeout from 10 seconds to 20 seconds in "Connection tracking" window.

5nik · Tue Aug 09, 2022 10:56 am

Me too:
RDP (TCP+UDP, Win10->Win2012R2) over SSTP VPN terminated on RB1100AHx2 (ROS 7.4). After increase UDP timeout to 20 sec RDP disconnection was fixed.

chrisknight · Thu Aug 18, 2022 8:02 pm

I also have this issue while using mstsc with server 2012 dropping either being remotely connected with road warrior wireguard, or PPTP.
I'm on 7.4.
***edit***
I can confirm that changing the UDP timeout to 20 seems to have fixed this issue for us on two different MikroTik's.
Can anyone please confirm how the default UDP timeout setting is set on 6.x firmware?

gpapili · Tue Sep 06, 2022 9:27 pm

I found this forum and it was very helpful:
We have a lot of offices with different servers, SSTP connections over offices, and W2012 servers on a few of them.
After upgrading to ROS 7, the RDP Disconnection problem started. We had to change the UDP time out to 20 sec, and also disable the Allow Fast Path on Bridge configuration to bring a final fix.
Now it is working fine.

vtikas · Wed Oct 12, 2022 5:16 pm

hi

I must miss led you I pass my log its not a rule
if you want some code to paste in termilal try this:
Code: Select all
ip/firewall/connection/tracking/set udp-timeout=20s
windows reconnect exactly 75 seconds apart. After five try's every 15s apart.
Thanks ! It works !

You rule !!!!

SiB · Mon Oct 17, 2022 12:55 pm

rafalgit write

hi

I must miss led you I pass my log its not a rule :?
if you want some code to paste in termilal try this:
Code: Select all
ip/firewall/connection/tracking/set udp-timeout=20s
windows reconnect exactly 75 seconds apart. After five try's every 15s apart.

+1, this #23 answer is solution.
This should be changed in auto-migration process.
Why this setting at ros6 as 10s not couse us any problems ?

gigx205 · Tue Oct 18, 2022 10:17 am

hi

I must miss led you I pass my log its not a rule
if you want some code to paste in termilal try this:
Code: Select all
ip/firewall/connection/tracking/set udp-timeout=20s
windows reconnect exactly 75 seconds apart. After five try's every 15s apart.

Great! It works! I had this problem for months on 2012 rdp via openvpn and wireguard....thank you, for now everything seems to be ok.

Tue Oct 18, 2022 9:08 pm

rafalgit write

Why this setting at ros6 as 10s not couse us any problems ?

Good Question

maybe in 7.x Connection track works somewhat different, i hope better way

Znevna · Tue Oct 18, 2022 9:44 pm

You all seem to ignore a reply from above:

Thank you. Increasing the udp timeout fixes the issue. Looks like v7 does not detect properly udp streams.

kelarlee · Fri Oct 21, 2022 5:25 pm

hi

I must miss led you I pass my log its not a rule
if you want some code to paste in termilal try this:
Code: Select all
ip/firewall/connection/tracking/set udp-timeout=20s
windows reconnect exactly 75 seconds apart. After five try's every 15s apart.

Thank you very much! You saved my day

Using 7.5 CHR and Windows 2012 R2, increasing udp interval solved my problem. Just interesting why no one from developers still not answered why this problem still presist in 7.x.x ROS ?

td32 · Fri Oct 21, 2022 9:23 pm

Can anyone please confirm how the default UDP timeout setting is set on 6.x firmware?

6,47.10

                   enabled: auto
      tcp-syn-sent-timeout: 5s
  tcp-syn-received-timeout: 5s
   tcp-established-timeout: 1d
      tcp-fin-wait-timeout: 10s
    tcp-close-wait-timeout: 10s
      tcp-last-ack-timeout: 10s
     tcp-time-wait-timeout: 10s
         tcp-close-timeout: 10s
   tcp-max-retrans-timeout: 5m
       tcp-unacked-timeout: 5m
        loose-tcp-tracking: yes
               udp-timeout: 10s
        udp-stream-timeout: 3m
              icmp-timeout: 10s
           generic-timeout: 10m
               max-entries: 217960
             total-entries: 3

pató · Thu Nov 17, 2022 12:59 pm

This isn't fixed in RouterOS 7.6.
We still have this problem with our 4011.
Thanks for the help I modify the UDP Timeout to 20s and it's fixed the problem.

dfdf · Tue Nov 29, 2022 7:02 pm

I have the same problem with RDP on Windows Server 2012 R2. I managed to force the end the cyclic disconnection by reducing the MTU from 1500 to 1492. I reported a problem with version 7.x and RDP to technical support. I think he doesn't believe me, than this problem exist. Also write to them, if there are more of us, they may believe.

Can confirm this on ROS 7.6 with RB750Gr3. Increased UDP timeout from 00:10 to 00:20 -- didn't help.
After that (having UDP timeout 00:20) decreased MTU on WAN ethernet port from 1500 to 1490 -- no more drops and re-connections, also no re-connections in Connections tab in winbox.
Didn't know exactly how WAN is feeded to router (I mange this router from other country), so can suppose there's some kind of xDSL connection may exist there (with modem in bridge mode), and maybe this is the root cause of the problem. Observing in/out ratio speeds in speedtest my suggestion about DSL is almost 100% correct.
RDP to Windows 2012R2 with TCP+UDP mode. Observed behavior is exactly as described in: viewtopic.php?t=178364#p898132

UPD: still having this problem, only disabling UDP (disabling dst-nat for 3389 port proto=udp) "solves" issue. But this workaround is very bad, cause on unstable connections UDP can be more reliable for RDP than tcp.

Tue Dec 06, 2022 9:28 am

We have been trying to reproduce this problem, but at the moment it seems that UDP timeout is a very good workaround for actual Windows Server issues. Of course, we want to get to the bottom of this.

1) Are all of the affected connections related to the Windows Servers? If yes, then which versions? We have discovered several forums and articles on the Internet stating that Windows Server itself has been having some issues with UDP mode. Can anyone confirm if the issue is present with the latest available Windows Server version?
2) Can everyone confirm that the exact same problem is not present if you downgrade the router to v6? If yes, then can you measure what is the interval of UDP packets within this RDP connection? It is possible that simply in v6, for example, UDP packets were processed within 9 seconds and in v7 they are processed in 11 seconds (basically living on the edge of UDP default timeout of 10 seconds). This is just a trivial example, but the question remains - what is the interval of UDP packets within the RDP connection on v6 and v7?

SyncRoot · Wed Dec 14, 2022 6:48 am

Having the exactly same disconnect problem today.

RB4011 RouterOS 7.6
Windows 10 Pro 21H2 19044.2251
Windows Server 2012 R2 Essentials 6.3.9600 Build 9600

RDP Connection breaks every 60-90 seconds.

The WireGuard in ROS is set up with MTU 1420.
While also have the change-mss configured.

/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn
add action=change-mss chain=output new-mss=clamp-to-pmtu passthrough=no protocol=tcp tcp-flags=syn

Problem successfully fixed by increasing UDP timeout from 10 seconds to 20 seconds

After some other research, find out there was already an existing UDP RDP issue with Windows Server 2012 R2.
https://social.technet.microsoft.com/Fo ... inserverTS
https://support.microsoft.com/en-us/top ... cee18a6eb3
https://support.microsoft.com/en-us/top ... 7ae1bb50b0
Have tried the solution provided in the first link, not working.
Check the patch history in my WS 2012 R2, the patch KB2984006 had already been installed years ago.

Turns out that the final solution for this issue is still to increase the UDP timeout in RouterOS

Other links that might be useful:
https://success.trendmicro.com/dcx/s/so ... rigin=null

Ibersystems · Thu Dec 15, 2022 2:02 pm

@strods, we had the issue with 3 diferent v7 versions to a win 2012 r2 server includong last v7.6. 20s udp timeout fixed the issue.

Same configuration in last v6 to same server with 10s default udp timeout is working fine with no cuts.

Its like not related to the board. We tested 4011 in v6 and 7 and 2116 board with v7. Both v7 are not working fine. V6 is working.

Fri Dec 16, 2022 10:31 am

Can anyone here please do the following:

1) Capture just the UDP RDP packets for a single RDP connection between two RDP devices from a failed connection in v7;
2) Do the same in v6 when the connection is working properly without any changes in configuration?

Send these capture files to supprot@mikrotik.com.

We have built a common firewall between two Windows Server devices and they communicate over UDP RDP without any problems. It seems that we are missing some little detail in order to reproduce this issue.

cynicism · Wed Dec 21, 2022 12:07 am

Some more information to help in recreating the issue:
It ONLY shows up when the Remote Desktop host is a Windows Server 2012 R2 computer. Windows Server 2008, 2016, 2019 do NOT exhibit the issue.
We can reproduce this issue using RB3011 and CCR1016, so a specific board does NOT seem to be relevant.
We can reproduce this issue using the Remote Desktop Client on both Windows 10 and Windows 11.
We started seeing the issue only after upgrading to ROS v7.6 (from v6.49).
Setting udp-timeout=20s does work around the issue successfully for us.

Psiho · Wed Dec 28, 2022 10:31 pm

+1 confirm

I got this problem just after upgrade 6.48 to 7.6 and ONLY with Windows2012 R2. UDP timeout 20s fix the issue. Waiting with BIG interest reply from tech support - what is going wrong with ROS 7.* and RDP server exactly Windows2012 R2

Fri Jan 06, 2023 9:09 am

Unfortunately, we still have not received any packet captures from the problematic scenario. If anyone is ready to share them, then please send .pcap files to support@mikrotik.com. Also please include supout file just in case.

pvlcek · Sat Jan 07, 2023 1:50 pm

I can confirm that setting UDP timeout to 20s resolves the issue. For me with Server 2019. However, the machine is not fully patched yet and I'm not sure when it is going to be. I can also share an interesting observation - when downloading torrents (with DHT enabled) this increased UDP timeout makes for much smoother experience for the rest of the computers when they use browsers. Browsing the web just feels much snappier. However, I do not know why. The only thing I can see is that the CPU load is about 5-10% lower (RB750Gr3, Qbittorrent set to 30 connections per torrent, 40 connections max, 10 upload slots max)

Maggiore81 · Fri Jan 13, 2023 12:53 pm

I can confirm that setting UDP timeout to 20s resolves the issue. For me with Server 2019. However, the machine is not fully patched yet and I'm not sure when it is going to be.

How can you keep a running server with no patches ?

mkx · Fri Jan 13, 2023 2:10 pm

How can you keep a running server with no patches ?

You should try it yourself some day, you'll be surprised how easy it is. It's easier than having it fully patched ... you don't have to anything.

lucius · Sat Jan 21, 2023 2:04 am

We have built a common firewall between two Windows Server devices and they communicate over UDP RDP without any problems. It seems that we are missing some little detail in order to reproduce this issue.

I think most users have NAT in between WAN and LAN. Perhaps you could setup a test environment that has NAT on the router, in which case conntrack is working and bugs in it would show up.

Btw, I also had the same issue, resolved by increasing UDP timeout to 20s in conntrack. It could be that ROS v7 doesn't properly track UDP streams in conntrack.

SyncRoot · Thu Jan 26, 2023 6:08 am

Unfortunately, we still have not received any packet captures from the problematic scenario. If anyone is ready to share them, then please send .pcap files to support@mikrotik.com. Also please include supout file just in case.

As I my environment requires the WireGuard to connect the win 2012, I can only provide the pcap files under the ROSv7.
I have sent them out, hope it still help.

Whitehawk29FR · Tue Feb 28, 2023 9:32 pm

Any news on this ? Why increase UDP timeout to 20sec solve the issue ?
Also affected by this windows 2012 disconnections ..

On wireshark capture I can see TCP RST packets sended to the server.

breakaway · Wed Mar 29, 2023 2:10 am

I have the same issue now. I upgraded from a RB750gr3 on v7.8 (which I ran for almost a month), zero issues on that one.

I upgraded - now I have a RB5009 on v7.8. Every 65 sec, the RDP connection would disconnect. Happened from two systems on my network - One Win 10, one Win 11 (at least windows has problems - I do not RDP out form Mac or iOS so can't attest to that). I broke out wireshark which showed TCP RST on both sides.

FWIW, the remote side is a combination of Win 2012 R2 server, Win 2016, Win 2019.

At first I was skeptical extending udp-timeout from the default 10s to 20s would fix it, but it has. - I assumed the command prefixed with

/ip/firewall/

was for hte IPv4 stack. But somehow, this command is for both IPv4 AND IPv6 stack?

This is the new updated setting (see udp-timeout) that makes my RDP connections stable:

/ip firewall connection tracking
set enabled=auto generic-timeout=10m icmp-timeout=10s loose-tcp-tracking=yes tcp-close-timeout=10s \
    tcp-close-wait-timeout=10s tcp-established-timeout=1d tcp-fin-wait-timeout=10s tcp-last-ack-timeout=10s \
    tcp-max-retrans-timeout=5m tcp-syn-received-timeout=5s tcp-syn-sent-timeout=5s tcp-time-wait-timeout=10s \
    tcp-unacked-timeout=5m udp-stream-timeout=3m udp-timeout=20s

Can someone clarify if the settings updated with

/ip/firewall/connection/tracking

are applying to both the ip4 AND ip6 stacks on the Mikrotik?

This is quite clearly a bug, if it works on Rb750gr3 and not on Rb5009.

EDIT: Just experienced the very same fault on a RB750gr3 running 7.8.

gtb · Thu Apr 20, 2023 1:07 am

WAS WORKING: RB750G r3 with RouterOS 6.49.6, with site to site IPSEC VPN, and L2TP/IPSEC VPN. Users connect to Server 2019 Remote Desktop Server across the site to site and road warrior L2TP/IPSEC VPNS.

UPGRADED (!) to RB4011 with Router OS 6.49.7, all same settings.

ISSUE!!! >>>> RDP connections refuse to establish across either of the VPNS

FIXED Site to site vpn by increase UDP timeout from 10s to 20s, thanks everyone!

STILL ISSUE >>>> RDP cannot connect via L2TP/IPSEC VPN "Remote Desktop can't connect to the remote computer for one of these reasons... 1) Remote access to the server is not enabled 2) The remote computer is turned off 3) The remote computer is not available on the network"

TRY FIX: disable fastpath for IPSEC
/ip firewall mangle add action=mark-connection chain=forward comment="mark ipsec connections to exclude them from fasttrack" ipsec-policy=out,ipsec new-connection-mark=ipsec
/ip firewall mangle add action=mark-connection chain=forward comment="mark ipsec connections to exclude them from fasttrack" ipsec-policy=in,ipsec new-connection-mark=ipsec
/ip firewall filter add action=fasttrack-connection chain=forward comment="Fast Track estab and related except IPSEC" connection-mark=!ipsec connection-state=established,related
(banged the fasstrack rule to top of ip firewall filter rules, disabled old "Fast Track established and related" rule)
... STILL ISSUE

ACTUAL FINAL FIX: I noted that the IP Pool for the VPN users was a subrange of the LAN range - this had looked weird to me, but I figured smarter people than me had set it up, so I had left it alone. But it bugged me, does not seem to conform to normal rules for routing - so in the face of all these troubles I edited my IP pool so its now on its own range (192.168.5.x - little joke there coz 5 in latin looks like V for VPN) - and I added the 192.168.5.0/24 range to my LANandVPN list so my firewall lets VPN users do whatever LAN users can do...

SUCCESSFUL CODE SNIPS:
add name=pool-L2TP ranges=192.168.5.200-192.168.5.250
add address=192.168.5.0/24 list=LANandVPN

rplant · Fri Apr 21, 2023 3:45 am

UPGRADED (!) to RB4011 with Router OS 6.49.7, all same settings.

STILL ISSUE >>>> RDP cannot connect via L2TP/IPSEC VPN "Remote Desktop can't connect to the remote computer for one of these reasons... 1) Remote access to the server is not enabled 2) The remote computer is turned off 3) The remote computer is not available on the network"

Possibly original config had proxy arp enabled on bridge.

J3SN · Wed Sep 20, 2023 3:02 pm

Are there any updates regarding this issue?

I am experiencing issues on RouterOS 7.11.2 running on CCR1009 hardware with UDP traffic between a server and clients in different VLANs.

The clients "lose" the connection to the server and recover almost immediately, however, the brief interruption is really negative for the user experience

Since the VLANS are managed on the CCR1009, I've changed the udp-timeout from 10 seconds to 20 seconds, as suggested above.

 /ip firewall connection tracking
set udp-timeout=20s

This has improved the situation for me because for a while now I don't see any of those weird reconnects in the server logging. I still don't quite understand why this adjustment makes a difference, which I'd like to know.

Even though I don't think NAT has anything to do with it, I still modified the firewall with the following rule for any WAN traffic, as also suggested above.

 /ip firewall filter
 add action=accept chain=forward comment="all from WAN DSTNATed" connection-nat-state=dstnat connection-state=new in-interface-list=WAN

From what I understand, these modifications can do no harm but I would like to understand the situation better.

rplant · Tue Sep 26, 2023 4:46 am

Are there any updates regarding this issue?
...
From what I understand, these modifications can do no harm but I would like to understand the situation better.

Hi,
Some thoughts,

The mikrotik firewall is usually stateful.

If you have a rule like, let any device on vlans x,y,z connect via UDP to server A on Port X. A new connection from a device on these vlans can be made to the server on port X and will be tracked.

To get the tracking into the UDP assured state needs 3 packets, the initial one from the client, a return packet from the server, and then a 3rd packet from either the server or client. If it doesn't get the 2nd or 3rd packets before each udp timeout interval (10S, 20S) the connection will disappear, and the server will not be able to send any more udp packets to the client. (each udp packet restarts the udp timeout)
If all 3 packets happen, the udp stream timeout is enabled. (3 min or as configured)

**
There may (or may not) be some very obscure edge cases where this doesn't work properly, if you found one and could replicate it.
I am sure Mikrotik would like to hear your results.
**

Another option is to have a reverse rule that says, udp Port X on Server can connect to any UDP port to any client on vlans x,y,z (assuming clients connect from a random UDP port, limit as appropriate)
This should mean that none of these packets will be dropped in either direction whether tracked or not.

Also in this case, it is possibly worth using the raw table to not track these connections at all.
Though it is perhaps nice (but expensive) to be able to view them in the firewall connections table.

nescafe2002 · Tue Apr 30, 2024 12:45 pm

This has been resolved in default configuration:

What's new in 7.14 (2024-Feb-29 09:10):

*) firewall - increased default "udp-timeout" value from 10s to 30s;

With the following explanation from support (dec 2023):

For starters, in Linux newer Kernel versions (in RouterOS terms - v7) UDP stream is delayed for 2 seconds. That is done by Kernel for some reason. So, for example, if your RDP connection did reach stream status in the past somewhere between 8-10s, then it worked with v6, but will not work with v7.

As for the connection itself. We have inspected problematic connections and RouterOS is doing everything properly from our point of view. All packets are processed properly, connections are treated properly. Simply these UDP connections can be time-consuming and seems that simply RDP has a bit longer stream establishment compared to other UDP streams. That is why it was the one which was noticed after an upgrade to v7.

We will consider increasing default udp-timeout values in the future RouterOS releases.

euisraelcunha · Tue Jun 18, 2024 2:34 am

estava com esse mesmo problema. muito obrigado pela dica.
resolvido meu problema aqui.
obrigado

Translated:
I was having the same problem. Thanks a lot for the tip.
Solved my problem here.
Thank you

hi

I must miss led you I pass my log its not a rule
if you want some code to paste in termilal try this:
Code: Select all
ip/firewall/connection/tracking/set udp-timeout=20s
windows reconnect exactly 75 seconds apart. After five try's every 15s apart.
Thanks ! It works !

Tesar · Wed Aug 21, 2024 10:37 am

Just for the sake of interest. Problem only occurring using default Windows RDP client. Using Remmina from Ubuntu works just fine.

Who is online