Hi all,
I am trying NAT rules on MK to mimic this Solution #2 – Policy Twice NAT on One side on this article https://www.practicalnetworking.net/stand-alone/vpn-overlapping-networks/ but cant get it working ;( So asking for you all maybe someone has this kind of knowledge how to implement this ? So far no luck in my logic.
Doesn’t it take less effort to change the IP pool on one of the side?
If you have multiple offices it is always a bad choice to put the same IP pool everywhere…
Basic starting point, yes.
Make sure to never have duplicate IP ranges on multiple sites...
192.168.0.x is customer network, same subnet is used at multiple locations
192.168.111.x is server network
10.208.50.x is customer network seen from the server side (all IPs from 192.168.0.x network get mirrored to it, for example 192.168.0.5 is reachable at 10.208.50.5)
# Phase 1
/ip ipsec profile
add name=hector dh-group=ecp256 enc-algorithm=aes-256 hash-algorithm=sha512 lifetime=1d nat-traversal=no
# Phase 2
/ip ipsec proposal
set [ find default=yes ] disabled=yes
add name=hector auth-algorithms=sha512 enc-algorithms=aes-256-cbc pfs-group=ecp256 lifetime=8h
# peer and PSK
/ip ipsec peer
add name=hector address=xxx.xxx.xxx.xxx/32 exchange-mode=ike2 profile=hector
/ip ipsec identity
add peer=hector secret=xxxxxxxxxxxx
# Network
/ip ipsec policy
set 0 disabled=yes
add dst-address=192.168.111.0/24 level=unique peer=hector proposal=hector src-address=10.208.50.0/24 tunnel=yes
# Firewall and 1:1 NAT Netmap
/ip firewall address-list
add address=192.168.0.0/24 list=hector
add address=192.168.111.0/24 list=hector
add address=10.208.50.0/24 list=hector
/ip firewall filter
add action=accept chain=forward src-address-list=hector
/ip firewall nat
add action=netmap chain=srcnat dst-address=192.168.111.0/24 src-address=192.168.0.0/24 to-addresses=10.208.50.0/24
add action=netmap chain=dstnat dst-address=10.208.50.0/24 src-address=192.168.111.0/24 to-addresses=192.168.0.0/24
Thank you dadaniel. I will try your setup on lab if this what i was looking for.
For all yes i know about IP subnet planing, but sometimes you have clients with less knowledge about anything like it. More - they do not want do any change on there network for reason.
Not go too as i have server in a same subnet as a client has in the same subnet ;( Any suggestion welcome again.
I cannot do anything on other side router “BiurasB”.
192.168.111.x is server network
is on BiuraA with the same subnet 192.168.1.0/24
Repeat …
Overlapping subnets is not a good long term solution. It will cause confusion to people at both sites, because to get it to work you have to make each site believe the other is on a different network than they are locally. Consider people trying to access the server from the other location, and they ask what ip address the server is on. The answer they get will probably be from the server side’s perspective, and that will not work from the other side using the same subnet as the server is on (but connected to a different instance of that subnet on a different broadcast domain).
That is pointed out in Ed Harmoush’s article, under
VPN Overlapping Networks: The Solution
The solution to the problem is to convince each host that the other host is on a foreign network. That would cause them to send packets to the Router, which can then send them through the VPN tunnel.
You could achive this using the “Solution 1”, but I am not aware of any way to implement “Solution 2” where everything is done on the same router, because I believe doing so requires VRF (and what MikroTik calls VRF is very limited, you still can’t have the same subnet in two routing instances that I am aware of, but I could be wrong; if someone knows how to do this on MikroTik please speak up and point to the relevant documentation).
You could probably do what you want by adding an additional router between BiurasA and the local (on left) 192.168.1.0/24 subnet, but it seems that renumbering the left side subnet would be easier, and a much better long term solution.
If you plan to use VPN, use an uncommon RFC1918 subnet. Here’s why: Local IP scheme interferes with VPN usage of other network and another example: Most common default ip subnets in this post.
Use (true) IPv6 and you solve.
That’s the same as having no overlap 
yes, but the IPv4 can remain the same 
That article just uses a mystical “twice nat” name for dst-natting the requests coming from Site A subnet X to subnet Y used on Site A as an alias of Site B subnet X, and then src-nating those requests to subnet Z used as an alias for Site A subnet X at Site B. If all connections are initiated from Site A, the following rules are sufficient:
chain=dstnat action=netmap dst-address=Y.Y.Y.0/24 to-addresses=X.X.X.0/24
chain=srcnat action=netmap src-address=X.X.X.0/24 to-addresses=Z.Z.Z.0/24
So VRF is not necessary, but policy routing is, as you have to say that packets whose destination address was from Y before the dst-nat operation have to be routed via the VPN even though at the time of routing their destination address is from X. Mangle rules assigning routing-mark values depending on the Y value and additional routing tables, one per each Site B, are enough for that.
At Site B, you just add a route to Z.Z.Z.0/24 via the VPN tunnel.
In addition to all the usual issues associated with use of NAT, you also need a distinct Y subnet for each Site B.
If connections need to be initiated also from Site B towards responders on Site A, you either need a distinct Z subnet for each Site B as well or you must use some other criteria, such as the name of a virtual interface representing the tunnel to Site B on Site A, to choose the appropriate netmap rule changing source address X to the proper Y if you want the responders on Site A to be able to unambiguously identify the initiators. And even if you don’t need this, you have to use connection marks to allow the responses to be routed properly.
Just for the sake of completeness, as use of VRF is not necessary in the scope of this topic - if we leave aside a “hairpin cable” connecting two physical interfaces of the same router, I don’t know any direct way to leak subnets between VRFs on the same physical router, but you can use a hairpin tunnel whose one end is a member interface of VRF 1 and the other end is a member interface of VRF 2. The only kinds of tunnels that can be used in hairpin mode in RouterOS are IPIP and GRE ones as these use no IDs that allow to create multiple tunnels between the same two devices, so RouterOS has nothing to check for uniqueness when you add the second endpoint of the tunnel. Such a hairpin tunnel is useful also in other niche scenarios.
Ok thank you all for the good discussion. TA least now i have good understanding about this problem and solutions about this kind “twice nat”.