IPSec Policy brokes packet flow.

[gRoot]

I’ve got the following configuration.

R1 config

# R1
/system identity
set name=R1
/ip address
add address=10.1.2.1/30 interface=ether1 network=10.1.2.0

R2 config

# R2
/system identity
set name=R2
/ip address
add address=10.1.2.2/30 interface=ether1 network=10.1.2.0
add address=10.2.3.1/30 interface=ether2 network=10.2.3.0
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=10.1.2.2 dst-port=1111 protocol=tcp \
    to-addresses=10.2.3.2
add action=src-nat chain=srcnat dst-address=10.2.3.2 dst-port=1111 protocol=tcp \
    to-addresses=10.2.3.1
/ip ipsec peer
add address=1.2.3.4/32 name=peer1 passive=yes    
/ip ipsec policy
add dst-address=10.1.2.0/30 peer=peer1 src-address=10.1.2.0/30 tunnel=yes

R3 Config

# R3
/system identity
set name=R3
/ip service
set telnet port=1111
/ip address
add address=10.2.3.2/30 interface=ether1 network=10.2.3.0

Everything works fine and predictable until IPSec policy appears.
With IPSec policy, even not active, packet go through dst-nat and disappear somewhere in “ROUTING DECISION”, probably.

So, my question is not about IPSec config, it is totally wrong. My question about packet flow and an influence of IPSec on packet flow.

Why packet disappeared after PREROTING (dst-nat)?

[sindy]

What you describe is an intentional behaviour, which is required by the IPsec RFC. In short, a packet matching a traffic selector of any existing policy with action=encrypt must not be sent, nor received, in any other way than via the security association linked to that policy, for security reasons.

A similar thing happens when you set rp-filter under /ip settings to anything else but no; here, packets came in via a “wrong” interface are also silently dropped.

In your case, what adds even more confusion is that the packets that should have arrived via an IPsec SA but came in plaintext are shown in the dstnat counters and dropped afterwards.