Router OS V7 TCP Retransmission vpn site to site two mikrotik

RouterOS General
1

hi, guys thanks for time and help i have a issue
i have a vpn site to site using two mikrotik routers but it has been impossible for me to be able to work from one of the offices connected to a sql server at the other end of the vpn, everything works except this service I have port 1433 open I connect to the server but when I execute a query it stays running query verifying with wire shark I get many TCP Retransmission

when i try to run one simple query i get this error on wire shark:

373680	8404.927512	10.100.20.110	172.16.100.11	TCP	1436	[TCP Retransmission] 1433 → 55705 [ACK] Seq=18087 Ack=1224 Win=261376 Len=1382




378905	8624.636501	172.16.100.11	10.100.20.110	TCP	70	[TCP Retransmission] 55705 → 1433 [PSH, ACK] Seq=2982 Ack=69807 Win=262656 Len=16

from windows client i do the next test and i have access in the port in both directions

PS C:\Users\Administrator> Test-NetConnection -ComputerName 10.100.20.110 -Port 1433


ComputerName     : 10.100.20.110
RemoteAddress    : 10.100.20.110
RemotePort       : 1433
InterfaceAlias   : Ethernet0 2
SourceAddress    : 172.16.100.11
TcpTestSucceeded : True
2

“TCP Retransmission” + VPN = MTU Problem

I’m guess ping is disabled on the SQL Server so PMTUD isn’t working. Basically on Windows Server you want to make sure PMTUD discovery is enabled/working (e.g. which is allowing ping). There is a registry you’d want to make sure was enabled: “EnablePMTUDiscovery=1”. Allowing ping in the windows firewall might also fix PMTUD discovery, and thus fix MTU issues and the TCP retransmissions you see. Been a while since used Windows Server, but basically you want to make sure PMTUD discovery is allowed on your SQL Server (maybe google help here since WS2XXX versions might be different, IDK).

As an alternative, you can try a mangle rule to change the TCP MSS size on the Mikrotik side as an alternative (e.g. tell TCP to use smaller packets). Replace XXXX with the site-to-site VPN interface name (or do FW filter match by IP, address-list, or whatever you’d like instead, as long as it’s traffic going over the VPN)…

/ip firewall manage add action=change-mss chain=forward in-interface=XXXXXXX log-prefix=MSS new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1232-65535

You’d also want to make sure icmp is allow on the Mikrotik routers in /ip/firewall/filter, but that a default in RouterOS.

If that doesn’t work… More questions: What kinda VPN are you using? What’s the MTU on the VPN interface? …

3

hi thanks for your time and help i am using ipsec vpn site to site and mtu is the stock mtu on both routhers.

4

Amm0’s point is that a VPN eats into the MTU limit. You have to deal with that somehow, either by clamping it statically or letting the auto-configuration signals through. He showed both options.

5

Hellos guys i set this on both mitrotik and stillg getting sql troubles over the ipsec vpn site to site


 0    chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp in-interface=ether2 tcp-mss=1232-65535 log=yes log-prefix="MSS"




 1    chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp out-interface=ether2 tcp-mss=1232-65535 log=yes log-prefix="MSS"
6

That solution requires PMTUD to work. Did you unblock ICMP/ping per Amm0’s prior reply?

See: Is it a bad idea for a firewall to block ICMP?

7

yes i have ping(ICMP) from A TO B and B TO A

8

Strange. Is the WAN at either end PPPoE (or something with a lower MTU than 1500)?

It be curious to see what MTU is calculated on Windows SQL Server side, see this article on using ping with DF bit set:
https://networkcanuck.com/2013/06/10/troubleshooting-mtu-size-over-ipsec-vpn/

9

FWIW… I’m not sure how the TCP MSS mangle rule works with IPSec – so that may or may NOT be right, never test IPSec w/ adjust-mss mangle. :wink:

Why I suggest doing this “by hand” and using ping at both side to calculate the MTU – so can sort out if it’s even a MTU problem. Although the “everything works but one box” with TCP retrans points at MTU issue.

10

From site A to B: Max MUT 1389
ping XX.XX.XX.XX -f -l 1389

From site B to A: Max MUT 1393
ping XX.XX.XX.XX -f -l 1393

Site A:

 0    chain=forward action=change-mss new-mss=1389 passthrough=yes tcp-flags=syn protocol=tcp in-interface=ether2 tcp-mss=1232-65535 log=yes log-prefix="MSS" 

 1    chain=forward action=change-mss new-mss=1389passthrough=yes tcp-flags=syn protocol=tcp out-interface=ether2 tcp-mss=1232-65535 log=yes log-prefix="MSS"

Site B:

 0    chain=forward action=change-mss new-mss=1393 passthrough=yes tcp-flags=syn protocol=tcp in-interface=ether2 tcp-mss=1232-65535 log=yes log-prefix="MSS" 

 1    chain=forward action=change-mss new-mss=1393 passthrough=yes tcp-flags=syn protocol=tcp out-interface=ether2 tcp-mss=1232-65535 log=yes log-prefix="MSS"

Same Result TCP Retransmission

11

@Amm0 that is a good point and who is answering on the other side, the server/client or the router. When the router answers then on behalve then the VPN connection is
not used.

@all
Run the MTU adjuster on the returning traffic and check that the ICMP can also reach the client on the inside.

12

Settings made on both routers and I have TCP retransmission
1 - Ping A to B Ok
2 - Ping B to A Ok

Test-NetConnection -ComputerName 10.100.20.110 -Port 1433 Connection ok in both directions

how i can check if the routeros really is changing the mtu?

13

Hmm… That’s ODD that the MTU is different between the two side. And even more curious it’s off by 4 bytes too. e.g. Is WAN interface’s config MTU off by 4 bytes on one side as that about the only explanation that make sense… If you had an idea why they be different, that be helpful… :wink:

But…I think your math is wrong in the the set-mss= is now part of the problem. See MTU is NOT the same as TCP MSS – so you can’t take the value from ping and use that directly in the set-mss=. And what ping with DF tells you is the max ICMP packet size – & TCP packets are bigger by 12 bytes than ICMP packets.

Anyway, we need to take lowest of your ping tests to do the math… so 1389 is the result from ping with DF set. The MTU then is 1389 + 20 (IP header) + 8 (ICMP header) = 1417 MTU. Now the MSS is 40 bytes less than the MTU (20 for IP, 20 for TCP headers).

So, I think, the Mikrotik TCP MSS mangle rule should be using set-mss=1377. Set this the SAME on both sides! Do not set them different on each side – that will break things! And why we’re using the lowest of the values since that’s what’s needed for MSS.

14

Look at the hit counter on the firewall rule – it should not be 0 :wink:

15

And the IPSec traffic goes though the firewall twice (tunnel then traffic)… It might be best to use the subnet IPs for the TCP MSS mangle rule – instead of the interface name in the adjust-mss rules.

But this is also why I suggest doing a little homework on the Windows Server running SQL Server. Older version of Windows disabled PMTUD from working. It takes both side for PMTUD to work… Mac and Linux all deal with PMTUD, and “recent” Windows… I just don’t know when the specific Windows version they changed their default firewall to allow PMTUD.

16

WireShark SQL Server:

67962	757.864236	10.100.20.110	172.16.100.11	TCP	1431	1433 → 62966 [ACK, CWR] Seq=35803 Ack=65 Win=1023 [b]Len=1377[/b] [TCP segment of a reassembled PDU]




69450	818.004392	10.100.20.110	172.16.100.11	TCP	66	[TCP Dup ACK 69448#1] 62966 → 1433 [ACK] Seq=65 Ack=37180 Win=1027 Len=0 SLE=38557 SRE=39934




69451	818.084644	172.16.100.11	0.100.20.11	TCP	60	[TCP Spurious Retransmission] 1433 → 62969 [ACK] Seq=43589 Ack=2112 Win=262144 Len=1

Config:

 0    chain=forward action=change-mss new-mss=1377 passthrough=yes tcp-flags=syn protocol=tcp in-interface=ether2 tcp-mss=1232-65535 log=yes log-prefix="MSS" 

 1    chain=forward action=change-mss new-mss=1377 passthrough=yes tcp-flags=syn protocol=tcp out-interface=ether2 tcp-mss=1232-65535 log=yes log-prefix="MSS"

The Same issue the only service whit issue in the vpn is the SQL Server.

17

See my most recent post. Try using the IP address in the mangle rule. It may be hit, but MSS adjustment of the tunnel itself (not inner traffic) isn’t going to help the remote LAN to SQL inner traffic…

18

Hold on here… Maybe cut-and-paste error, but this is very odd:

What’s at 0.100.20.11?

(and FWIW it looks like the MSS rule is working, at least one way since length=1377 from WireShark)

19

Hi guys still testing

From Site A (SQL SERVER) i get a Len=1377

389731	40.963863	10.100.20.11	172.16.100.11	TCP	1431	[TCP Retransmission] 1433 → 53004 [ACK] Seq=1417742 Ack=14247 Win=1025 Len=1377

But From Site B Client still send Len without changes still cheking config on router B

20

Still having troubles, one question the fastrack can it cause some kind of problem with ipsec?