There's this network:
The computer 192.168.10.4 wants to access a VPS server which has an OpenVPN server running on it, configured to use the subnet 192.168.20.0/24.
The computer's subnet also contains a SBC 192.168.10.2 configured to be an OpenVPN client connected to the beforementioned server. IPv4 forwarding is enabled on that SBC.
The default gateway of the computer is set to the network's router, which is running RouterOS on 192.168.10.1.
Here's the problem:
When I just add an entry in the RouterOS routing table, which tells to route all the traffic destined to the subnet 192.168.20.0/24 to the SBC at 192.168.10.2, then, upon each new connection to the VPS on 192.168.20.1, there's a 9 second delay before the connection get's established. Once it is established, the traffic flows fast.
If I change the default gateway of the computer to 192.168.10.2, that is, to the SBC, then the connections get established immediately.
Also, any connection from the SBC to the VPS get established immediately.
If I change back the default gateway to the RouterOS device, and create a SNAT masquerading rule on this device for destinations in 192.168.20.0/24, then connections get established fast on the computer, probably only because RouterOS is impersonating the computer.
How can I route to the VPS without a SNAT, and without that 9 second delay? What is causing that 9 seconds delay?
Now I've noticed that without SNAT certain devices are able to route correctly, that is, access a server on the VPS, without having that delay. All Linux boxes in the computer's subnet don't have problems with the routing, but most noticeable are Windows boxes, which sometimes do work, some never, some occasionally, depending on if another machine is online or not, then only not for a while. There's no clear pattern to me.
PD: It's always possible to ping the VPS's 192.168.20.1 address, from any host in the 192.168.10.0/24 network.