First of all let's look at following network diagram:


What I'm trying to archive is connecting from host "VPN Client" to "HServer-1". Since "HRoute" have another EoIP here's what I'll got if I try to ping "HServer" from "VPN Client":
1. 10.0.0.19 sends ICMP to 11.12.13.14
2. Due to route on client "11.12.13/24 10.0.0.1" packet is transmitted to "WRouter"
3. "WRouter" have a route to "11.12.13/24" network via EoIP, so packets is sent to "HRouter"
4. "HRouter" transmits packet to "HServer-1" via ARP lookup
5. "HServer-1" replies to "HRouter" with ICMP-reply src=11.12.13.14 dst=10.0.0.19
6. "HRouter" transmits following reply to "MRouter" since dst=10.0.0.19 matches route

Of course I can try to eliminate IP ranges conflict, but it's not a right path to follow in that case. I personally think "HRouter" should NOT know about (somewhat internal) routing on "WRouter" - packets should be NATed and than transmitted to "HRouter".

...and that's where I stopped No matter what I do packets from VPN are directly transmitted via EoIP to "HRouter".

That's the route on "WRouter" to direct packets to "HRouter" network: Relevant firewall filtering rules:
Any suggestions before I rip off all hairs from my head?

Of course I can try to eliminate IP ranges conflict, but it's not a right path to follow in that case. I personally think "HRouter" should NOT know about (somewhat internal) routing on "WRouter" - packets should be NATed and than transmitted to "HRouter".

I disagree with this. Don't break access by breaking layer3. If the VPN endpoints are a part of your system, then layer3 should have a complete map and reachability inside your network. Filter the access (as you suggested later in your post) with firewall filter rules.

All nodes should have full routes to all network segments. It's just good practice. If you ever need to troubleshoot connectivity problems, you don't need to worry about certain parts of the network being unable to reach other parts because of missing route statements or duplicated IP addresses. Make your IP layout straightforward and limit connectivity with filter rules.

If this isn't possible, then you can fix your problem by doing MASQUERADE at wrouter as you stated....
However, you will then lose visibility as to which VPN user is accessing servers at hserver. All connections will appear to be from Wrouter itself.

Unfortunately "MRouter" network is not controlled by my. "HRouter" network while controlled by my should be treated as external but accessible by VPN users (but also in limited manner).
There're gonna be few other networks connected to "WRouter" which have no IP conflict since there's clear design of address space (current address schematic for "WRouter" is just for tests there).

I've also find a very strange thing (it looks lika a bug). I've added src-nat with masquarade for eoip-to-hrouter. Also "WRouter" as I said before has a route to 11.12.13/24 network via EoIP. For few minutes I was able to ping 11.12.13.14 from VPN client, but after reconnection it's gone.
I begin investigating. To test that I've created MetaROUTER instance with MT inside, added 2 vif's and than added them to intranet bridge. They've got IPs from DHCP from 192.168.88/24 pool like normal devices connected physically to the router.
If I try to ping 11.12.13.14 from MetaROUTER instance packets are traveling to default gateway (which is physical MT) and than through EoIP tunnel to "HRouter". Reply is carried the same way. And now the magic is happening - if I disable that EoIP interface and re-eanble it, MetaROUTER loses ability to ping 11.12.13.14 for random amount of time.
Let's see that clip: https://www.dropbox.com/s/m23ce564jt9ch ... f.mov?dl=0 [on this demo "eoip-hera" is a tunnel to "HRouter"]
Also what I discovered pings from MetaROUTER are NEVER reaching 11.12.13.14 unless I first ping it for the first time from physical device.

Maybe it's related to my VPN problems? In theory to resolve whole problem described in 1st post only one rule is needed: Unfortunately it doesn't work like I expect. Am I missing something?


Edit:
After uploading movie to dropbox I added masquarade mentioned above and started ping from vpn client to 11.12.13.14 - it was 100% loss. After writing that post (which took me ~5 minutes) I've looked at VPN client screen and I discovered I'm getting replies from 11.12.13.14 - I'm puzzled now.
I tried pinging 11.12.13.14 from MetaROUTER - it's timeouting while physical router still can do it. After disabling EoIP tunnel and re-enabling ping from router was interrupted for few seconds while VPN client is now unable to reach 11.12.13.14 server.
After some try-error routines I discovered most of the time (but not always) I was able to restore ability to ping 11.12.13.14 after pinging 11.12.13.1 and restarting ping to 11.12.13.14 ... weird. Unfortunately that method doesn't seem to work on MetaROUTER instance - no matter what I do I need to wait few minutes to ping 11.12.13.14 again. Of course I have to restart ping.

Weird...
Another video: https://www.dropbox.com/s/wuflqilk77ogt ... 2.mov?dl=0