Is it possible to make PBR for IPSec? I mean I'd like to push all new outgoing connections through IPSec tunnel, but all connections incoming from world to servers to return directly, not via VPN tunnel..

If you use different addresses for incoming and outgoing connections and policy reflects that, it would work. Either give those addresses to servers directly, or you can use NAT on router.

If you use different addresses for incoming and outgoing connections and policy reflects that, it would work. Either give those addresses to servers directly, or you can use NAT on router.

I want servers to also go via VPN but only for server-initiated connections. So when user accesses server then server responds without VPN but when server downloads eg. updates then they should go via VPN (without PBR and two IPs on servers themselves).

But yeah it should be doable with NAT since I can do such NAT only for outgoing connections. That said I'm afraid policy matching is performed before NAT so I doubt that it would work when NAT and IPSec would be made by the same MikroTik. And when we're talking about two MikroTiks then I could just as well use standard PBR and redirect outgoing traffic to second MikroTik gateway that would only do IPSec. But I hoped for one-box solution. I already use two MikroTiks on the path (because I'm doing QoS on edge router and PBR on core. And since both use mangle it's pain in the ass to do both PBR and QoS on one box). I really don't want to introduce third one.

Some good news about NAT & IPSec, policy check comes after postrouting, which is where srcnat is:

https://wiki.mikrotik.com/wiki/Manual:P ... Decryption

Or it can be done without NAT, but you'd have to touch all servers, i.e. give each e.g. 192.168.X.x for incoming connections and 192.168.Y.x for outgoing.

I just figured out I'm dumb I didn't check that in CHR lab before. It turns out that additional /ip ipsec mode-config options unlock after actually configuring IPSec till the end. And there's option to apply mode-config to either src-address-list (not really what I want but that's what has been presented in official tutorial so I thought it's the only way) but also to connection-mark. Which is totally what I'm looking actually since now I can apply "incoming" connection mark to all incoming connections and basically apply IPSec to connection-mark=!incoming.

It's still useful to limit source of IPSec policy a bit in order to make hairpin work properly

.
.
Which is totally what I'm looking actually since now I can apply "incoming" connection mark to all incoming connections and basically apply IPSec to connection-mark=!incoming.

It's still useful to limit source of IPSec policy a bit in order to make hairpin work properly

!incoming = nomark

And there's option to apply mode-config to either src-address-list (not really what I want but that's what has been presented in official tutorial so I thought it's the only way) but also to connection-mark.

I forgot about that. It's very new and I didn't test it yet.

And there's option to apply mode-config to either src-address-list (not really what I want but that's what has been presented in official tutorial so I thought it's the only way) but also to connection-mark.

I forgot about that. It's very new and I didn't test it yet.

I just tested it in lab with setup mimicking my physical infrastructure - yeah it works, I can assign connection-mark tovpn to all connections that have in-interface=!ether1-gw and then use it in mode-config. And all connections coming from world will properly return unencrypted as expected. Unfortunately there's no way to negate connection-mark nor address-list in mode-config so you need to negate actual rules.