Hi,

I need to make a source nat (masquerading) of remote address assigned to OpenVPN clients.
That's because the mikrotik device is only used as VPN concentrator and is NOT the default gw of the LAN.
Since I can't add a static route on every server connected to the LAN I would masquerade the pool of private IPs assigned to the OpenVPN clients with the mikrotik's LAN IP.
In this way all the traffic coming from OpenVPN clients would appear to the servers as generated by the mikrotik, with no need to any extra route, being the private OpenVPN pool "hide" by this NAT.
Unfortunately src-nat rule doesn't match even if I set no filter parameter other than source OpenVPN IP pool (the counter doesn't increment at all).
It "seems" src-nat chain is not accessed by OpenVPN traffic, although the Packet Flow v6 states the traffic is before decapsulated to the virtual interface then processed by the chains.
(The bridged OpenVPN (tap) is not viable).

I just would src-nat 10.0.0.50-99 to 192.168.0.10 (please see the attached diagram for details).


Any hints?
TIA
Riccardo

Update: the problem doesn't occur with another VPN (IPSec) configured on the same VPN concentrator.

The src-nat rules implemented are the same but the first one related to OpenVPN traffic doesn't work (no packet match), while the second one works like a charm:

/ip firewall nat add action=src-nat chain=srcnat comment="OpenVPN traffic" out-interface-list=PRIVS src-address=10.0.0.200 to-addresses=192.168.0.10
/ip firewall nat add action=src-nat chain=srcnat comment="IPSec traffic" out-interface-list=PRIVS src-address=10.1.0.0/24 to-addresses=192.168.0.10

I'm wondering if this could be a mikrotik bug or a different "by design" behaviour.

Any suggestion will be highly appreciated.
Thanks
Riccardo

It won't be very helpful, but it works for me. And there's not really any reason why it wouldn't, same rules apply to all traffic passing through router. No new connection will bypass srcnat.

Hi Sob, thank you for your answer.
This is very useful as it shows that there is no reason why the rule should not work.
Unfortunately in my device it doesn't match at all, so there must be something that prevents it from working.
Could you please show me your rule (obfuscated if you want) so that I can troubleshoot mine?
Thank you
Riccardo

My rule won't help you, the only difference from yours is different subnet in src-address and out-interface instead of your out-interface-list, but that's nothing.

Do you have some other rules in srcnat chain that could interfere? What if you add following as very first rule in srcnat chain?

Hi Sob,

thank you for your help.
Because of you I've solved the problem: it was not caused by NAT rule but by a missing FILTER rule, that was causing no traffic could flow from PPP sessions (but when NATed only).
Adding the following made the "miracle":
Thanks again!!!
Riccardo