OpenVPN routing issues

Hi,
apparently I’m not the infrastructure/routing guy because I do not understand the issue I’m seeing.
I was maintaining a simple Linux gateway which I replaced almost completely with a RB2011UiAS. What I left with the Linux gateway was the OpenVPN tunnel endpoint for roadwarriors because the RouterOS implementation is really by far not up to standards unfortunately.
So what I did was a DNAT for the OpenVPN traffic to the Linux machine which works fine as far as I can tell but the VPN routing has an issue which I do not understand:
My openvpn server config:
server 10.8.0.0 255.255.255.0
Therefore my clients all have an IP from that network and my ROS routing entry looks like this:
1 A S ;;; VPN network
10.8.0.0/24 192.168.1.253 1
where the openvpn server is 192.168.1.253.

With that setting I experience issues already with pings to different servers/hosts in the internal network. Some pings work fine while for others I never receive a reply.
I cannot really make sense out of which targets work and which ones don’t but it also seems erratic. Also when I try to access an internal webservice through the VPN connection it looks fine in the beginning and then connection times out.
All hosts in the network have the RB2011 as default gateway but do not know themselves about the openvpn network.

It smells a bit like MTU but then again simple ICMP requests do not work reliably as well.
Can anyone point me into the right direction or can I provide any more debugging?

Do you drop packets with invalid connection state on your router? If so, check what exactly gets dropped. Because you now have asymmetric routing, packets from VPN go from OpenVPN server directly to internal target, but replies use “shortcut” via router. RouterOS sends redirects in this case, to tell source host to use the proper gateway directly, but some hosts might accept them and some might not.

Nice catch. You are right. I disabled now the “drop invalid” rule and everything seems to work fine.
What is the best practice in that case? I guess it’s better to have the “drop invalid forward” and insert a accept rules inbetween the internal and vpn ip range?

Thanks again for the quick pointer!

It’s generally good idea to drop invalid packets, so an extra rule for allowed exceptions is the solution.