Hi, today I tried to configure this kind of IPsec VPN (S2S):

HQ router (CCR1009)
WAN IP: 1.1.1.1
LAN IP: 10.1.1.1/23
PTP-to-RT2: 10.255.255.1/30

Branch office router (RB3011)
WAN IP: 2.2.2.2
LAN IP: 10.2.1.1/23

HQ router is connected to another router (IP 10.255.255.2/30) from which I know the subnet 10.0.0.0/8 (with a static).

I have the same problem that you can find here: viewtopic.php?t=118224

I've seen that the priority field was removed from v6.40 (and I have v6.42 installed), I've tried creating a policy BEFORE the one that encrypts but the effect is the same seen in the other topic: I cannot reach the branch office subnet even locally (it gives me a TTL expired error if I ping an host directly connected to the LAN).

Here is the policy export of the branch office:
The rest of VPN config is correctly working: testing it with remote subnet equal to the HQ office LAN subnet results in established tunnel (so DeNAT, firewall, phase1/2 configuration are ok).

Could you please help me?

Thank you.

Beppe

Exactly this kind of policy with action=none creating an exception from a following policy with wider match and action=encrypt normally works for me on 6.42 (not 6.42.x, just 6.42). But I had some issue with a wider policy with action=discard following a narrower policy with action=encrypt on 6.42.3, so maybe there was some regression. What is your exact version?

Hi Sindy, my version is 6.42.4
I've seen the changelog of 6.42.5 and there are no ipsec related change, so I don't upgraded routers.

Thank you for your support.

Kind regards,
Beppe

If you have a test routerboard, you may try to downgrade it to 6.42 and try the same configuration; if it works that way and after upgrade of that test unit to 6.42.4 you get the same problem, gents at Mikrotik will be glad to receive the trouble description together with supout.rif file on support@mikrotik.com. If you don't have one, let me know, I may be able to do that test in one of my setups but probably not soon enough that it would be useful for you.

I will try, thank you very much!

NAT both of the overlapping subnets to something unique. Conditional DNS forwarding can be used to overcome DNS based limitations.

I've written a few posts on the subject. It's commonly done for business to business VPNs here in the US to make each partner side look like certain addressing that fits into their scheme's to avoid RFC1918 overlap.

Alternatively, use IPv6 with global unicast addresses.

For example if 192.168.1.0/24 is used by both sides. Source NAT one side to 10.1.11.0/24 when destined for 10.1.12.0/24. Source NAT the other side to 10.1.12.0/24 when destined for 10.1.11.0/24. Use destination NAT to unwarp the 11/12 back to the locally significant 192.168.1.0/24 only when it's sourced from either 11/12.

It's commonly done for business to business VPNs here in the US to make each partner side look like certain addressing that fits into their scheme's to avoid RFC1918 overlap.

Well, the OP's issue here doesn't seem to be that the private (RFC1918) address spaces would overlap between the sites/networks being interconnected, but that the LAN subnet at the BO site is a subset of a larger subnet used network-wide. So he needs to let the policy collecting packets for the SA grab everything for that network-wide large subnet except packets for devices in his local LAN. So src-nat'ing (or netmap'ing) the traffic for the local LAN subnet would prevent the ipsec policy collecting packets for the SA from matching it, but the recipients would see it as coming from somewhere else.

So if you would e.g. ping the 'Tik's own address on the LAN from another device on the LAN, the response would come from some other 'Tik's address and the device would thus ignore it.

Therefore, he'd have to implement this upside down - use action=netmap in chain=srcnat to translate the source address of everything for 10.0.0.0/8 into some other subnet, let the IPsec policy match on that other subnet, and use action=netmap in chain=dstnat on the remote side to fix the source address back to the original one so that other networks for which the HQ router is a gateway to the whole 10.0.0.0/8 would see the traffic from the BO to come from its real source subnet.

Such a workaround will work so it may help temporarily, but the order of the policies should work normally so it should be fixed - if for no other reason, then because that in some other case the remote equipment may not be a Mikrotik one so the "un-netmap" may not be possible.

Sindy, I agree if there is a big to fix then let's fix it.

I'm just saying an alternative is the NAT approach. They can always NAT the small overlapping piece. I'd just NAT the whole thing to unique addressing on both sides to keep it clean. Exempting the traffic I assume means those hosts cannot talk across the link. This approach is non MikroTik specific. I actually learned the technique on Cisco ASA gear.

Well, I look at it from the perspective of my own scenario which is exactly the same - a star topology of small BOs all connected to a single HQ router which need to talk to each other without any NAT as the very purpose of that setup is to carry a VoIP network with direct routing of RTP. So there is a large private subnet and each BO occupies a subset of it. And where the IPsec policies work as they should, I simply place a "do nothing for packets whose both src-address and dst-address matches the BO's lan subnet" policy in front of the "real" one and I'm happy. So if I'd have to use NAT when sending from BO to HQ, I'd definitely have to use un-NAT on the HQ to keep things looking sane for the remote end