I need securely connect two routing networks, so I decide to use IPIP tunnel over IPSec running in transport mode between gateways.
Also it's needed not to run unencrypted traffic between networks.
So I configure IPSec and IPIP tunnel.
Also on both gateways I make filter rules to prevent not IPSec traffic between them.
Bottom is the simple configs from both gateways (to make tests I use CHR and RouterOS 6.40.5):

Config 1:
/ip address> pr
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 10.19.1.2/24 10.19.1.0 ether1
1 192.168.1.1/24 192.168.1.0 ether2
2 10.0.1.1/30 10.0.1.0 ipip-tunnel1

/interface ipip> pr
Flags: X - disabled, R - running, D - dynamic
# NAME MTU ACTUAL-MTU LOCAL-ADDRESS REMOTE-ADDRESS KEEPALIVE DSCP
0 R ipip-tunnel1 auto 1430 0.0.0.0 10.19.2.2 10s,10 inherit

/ip firewall filter> pr chain=input
Flags: X - disabled, I - invalid, D - dynamic
0 chain=input action=drop connection-state=invalid log=no log-prefix=""

1 chain=input action=accept connection-state=established,related log=no log-prefix=""

2 ;;; IKE
chain=input action=accept protocol=udp src-address=10.19.2.2 dst-port=500 log=no log-prefix=""

3 ;;; IPSEC
chain=input action=accept src-address=10.19.2.2 log=no log-prefix="" ipsec-policy=in,ipsec

4 chain=input action=drop src-address=10.19.2.2 log=no log-prefix=""


Config 2:
/ip address> pr
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 10.19.2.2/24 10.19.2.0 ether1
1 192.168.2.1/24 192.168.2.0 ether2
2 10.0.1.2/30 10.0.1.0 ipip-tunnel1

/interface ipip> pr
Flags: X - disabled, R - running, D - dynamic
# NAME MTU ACTUAL-MTU LOCAL-ADDRESS REMOTE-ADDRESS KEEPALIVE DSCP
0 R ipip-tunnel1 auto 1430 0.0.0.0 10.19.1.2 10s,10 inherit

/ip firewall filter> pr chain=input
Flags: X - disabled, I - invalid, D - dynamic
0 chain=input action=drop connection-state=invalid log=no log-prefix=""

1 chain=input action=accept connection-state=established,related log=no log-prefix=""

2 ;;; IKE
chain=input action=accept protocol=udp src-address=10.19.1.2 dst-port=500 log=no log-prefix=""

3 ;;; IPSEC
chain=input action=accept src-address=10.19.1.2 log=no log-prefix="" ipsec-policy=in,ipsec

4 chain=input action=drop src-address=10.19.1.2 log=no log-prefix=""

When IPSec is running I can connect from 10.19.1.2 to 10.19.2.2 and from 192.168.1.0/24 to 192.168.2.0/24.
When to check rules I stop IPSec and strange things - I still can connect from 192.168.1.0/24 to 192.168.2.0/24 but can't between 10.19.1.2 and 10.19.2.2.
I see that it works "Accept established,related" rule in input chain even then I drop IPIP tunel and clear connections tacking.
How to stop not IPSec traffic between networks?

The easiest solution would be to use the RAW table.
Create a rule in prerouting which matches IPIP traffic from the remote peer and uses the action "no track"
This way, the IPIP traffic will never be in the established or related state.

Although, I would say that you still run the risk of exfiltrated data because if you discard unencrypted traffic at the destination router, then the packets will have already crossed the insecure network. Perhaps a better way to do this would be to use purely internal IP addresses as the IPIP endpoints (such as a Loopback bridge interface on each router)
I think you could assign the remote router's loopback IP address to be learned dynamically via the IPSec session (which is still built using the two routers' public IP addresses), and have a floating static blackhole route to the remote loopback IP.

e.g.: 10.255.255.1 = site1's loopback IP. Site 2 associates the route 10.255.255.1/32 with the VPN session, which would override the static route dst=10.255.255.1/32 distance=254 type=blackhole

In this configuration, there's no need to block the unencrypted IPIP traffic because it can never reach you except via the IPSec tunnel.

I'm not entirely sure how to make the IPSec session learn the route, but I know that IPSec can do this (probably using dot1x authentication) - I'm just not well versed in IPSec, especially on RouterOS.

Thanks. Using RAW table helps. Another solution is to move IPSec rules above "established, related" rules.
I don't dig IPSec address subst now, but it also can work.

In any case it's oddly that ROS always treats IPIP packets as "established, related" even when creating tunnel.

In any case it's oddly that ROS always treats IPIP packets as "established, related" even when creating tunnel.

Not at all. Whenever you have connection tracking enabled (which is the default) then every connection is evaluated by the engine. The IPIP tunnel packets are in fact a conversation over a socket. Once the router has sent and received a packet on the socket, then the socket is established. So the established/related rule matches the established connection.

Think about it this way:
The router receives the IPSec packet which is processed locally. It contains an encapsulated IP packet which must be run through the packet flow again as a separate packet. The encapsulated IP packet contains an IPIP packet, so that also must be decapsulated. So if two hosts are pinging through the tunnel, you will have three established connections in the tracking table: IPSec between the routers, IPIP between the routers, and ICMP between the hosts.

Yes. There are several tracked connections (IPsec, IPIP and some kind of "usefull" -ICMP, TCP etc). But it's for case when all is good.

But I'm talking about broken IPSec router-to-router connection and moment of establishing IPIP tunnel.

So for beginning there are no IPSec now and no IPIP.
Then "first" router initiates IPIP tunnel (sends packet to "second" router without IPSec, because it's broken). "Second" router for now hasn't seen any packet before and has firewall rule to drop packet received without IPSec, but for some reason this FIRST (NEW) packet hits "established, related" rule and "second" router replies.

So for beginning there are no IPSec now and no IPIP.
Then "first" router initiates IPIP tunnel (sends packet to "second" router without IPSec, because it's broken). "Second" router for now hasn't seen any packet before and has firewall rule to drop packet received without IPSec, but for some reason this FIRST (NEW) packet hits "established, related" rule and "second" router replies.

That shouldn't be the case when starting from scratch - the IPIP traffic follows the same rules as everything else as far as I'm aware. If you break the IPSec after the IPIP has been established, then that wouldn't remove the IPIP connection from the firewall's tracking tables. If it's matching due to established,related, then that seems wrong to me. Try looking in the firewall connections tab for anything relating to the IPIP connection before the connection establishes.

One troubleshooting step would be to make a test rule for established,related connections, but also with src-address=the remote address of the IPIP tunnel. Make this the first rule in the input chain. Watch the counters on this test rule. (This is because the usual connection=established/related rule tends to match tons of traffic and it's pretty much impossible to tell whether hits counted on it are due to the traffic in question or just the usual stuff going on with the router). If this limited-scope test rule shows any matches, then the state tracking is indeed matching. If not, then it's not the state tracking but some other rule between the state tracking rule and the "drop unencrypted IPIP" rule.

Honestly, though, it might be a lot easier to just use SSTP instead of IPSEC+IPIP

Hello i try to make a ipip tunel behind a router, which is the ipip port to fw ?

Hello i try to make a ipip tunel behind a router, which is the ipip port to fw ?

There is particular IP protocol number 94 for IPIP (for IP protocol packet header's field).