2

I've installed Mikrotik hEX at location 'A', Mikrotik hAP AC^2 at location 'B', and connected each with OVPN L2. Both two routers have their NAT features turned on, and have their private network. hEX has network 192.168.0.0/23, and hAP has network 192.168.3.0/24. These two local networks are are bound as one local network 192.168.0.0/22. I've confirmed all bridge, routing and DHCP policy are configured and worked as I expected.

After configuring above setting, I'm trying to connect to an public IP ('X') from device attached under hEX, to use this route.

End device -> hEX -> hAP -(NAT)-> Remote server 'X'

To accomplish this, I've added routing policy to 'X' to use IP of VPN server binding interface on hEX as gateway, and confirmed ICMP echo reply is well received, stable, and requires about 9-12 ms to be replied.

However, when I use any software which is using TCP to establish connection(I've not confirmed if UDP is being affected too, but I think it is negative.), something strange happens like this: TCP PSH, ACK is being retransmitted for about 10 secs

Even other TCP packets are replying ASAP, under 50 msec, if TCP connection is established. However, only TCP ACK packet replying SYN, ACK of server is keep being retransmitted for about 10 secs and then handshake process is continued. This behavior is also found while HTTPS connection is established, and is observed at all devices under hEX.

If I remove routing policy to address X, then use route

End device -> hEX -(NAT)-> Remote server 'X', TCP handshake is immediately established.

If I connect to address X on device under hAP, by using route

End device -> hAP -(NAT)-> Remote server 'X', TCP handshake is immediately established.

What is the problem, and how should I fix it?

Sam
  • 45
  • 1
  • 1
  • 4

1 Answers1

0

After reading over your post and looking at the network trace screen shot you provided, I'll focus on that detail and the ICMP redirects in particular.

After doing some research on some of this, the "What does ICMP | Redirect | (redirect for host) mean?" post seems to have some potential solutions to help resolve this issue.

It's suggested that using static routes between the routers and/or not using overlapping subnets via subnet masks will help routers not automatically pick a better route causing the redirect which you've captured.

This all said, it seems to me that perhaps the routes are getting confused between the hEX -> nAP and hEX <- nAP hops in both directions and using static routes between may help.

Final Working Solution

The OP removed whole routing policy, which is represented as 'X' in the question, then added policies as DHCP option 121. This policy basically routes to hAP's IP on hEX (via VPN interface) for gateway.

Previously traffic to 'X' was routed by hEX then hAP, but now hEX is working as a switch and hAP is responsible only for routing and masquerading traffic to/from 'X'.

The ICMP redirect was a good clue and making a direct/static route is exactly what it took to resolve this issue.

Pimp Juice IT
  • 1,077
  • 1
  • 9
  • 16