0

There's this network:

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?

Update:

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.

Any idea?

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.

Daniel F
  • 353
  • 4
  • 16
  • 2
    `Any idea?` RouterOS may be sending an ICMP redirects that your devices clients aren't accepting. Should be pretty obvious if you just tcpdump and capture icmp traffic. – Zoredache Oct 30 '14 at 00:33
  • I will check that. But I thought ICMP redirects are only a suggestion from the part of the router so that the host can opt to choose a better route. In my case the "redirect", which might as well constantly flow though the router, it is a requirement, so I'm not sure if a ICMP redirect is anything that should play a crucial role here. – Daniel F Oct 30 '14 at 00:51
  • I'm planning to expand this later in an answer. You're apparently right with the ICMP redirect message. I read that it was a suggestion, but, according to technet and some unix resources ICMP redirect is the way to go if both routers are on the same subnet, and that hosts should not ignore those messages. --> But my problem was on the OpenVPN side. After fiddeling around with adding routes manually to both the VPS and the client, and then adding them to the ovpn file, I came across the `iroute` keyword, added a ccd file to the server and now it's working without any masquerading. Nice! – Daniel F Oct 30 '14 at 21:21
  • Uhm,... it worked for a moment :( – Daniel F Oct 30 '14 at 21:28
  • I noticed that if I restart the client and/or the server, I need to disable/reenable the routing entry in RouterOS. Now it's an issue with the routing table of the computer. – Daniel F Oct 31 '14 at 01:19

0 Answers0