Good day,
I have two Mikrotiks connected by an IPsec tunnel,
then I create an IPIP tunnel on both Mikrotiks and only this is the firewall rule
/ip firewall filter
add action=accept chain=input connection-state=established,related
add action=drop chain=input protocol=ipencap
The question is, why do both ends of the tunnel show the ready status, where is the new connection status? Or does such a state not exist for 4 (ip-encap)?
in other words, why does ipip tunnel keepalive pass through the established,related firewall rule?
The new state exists for the protocol. Most people encounter this sort of issue when they already have a connection in the “established” state and then create a drop rule, then wonder why it’s not applied.
I tried it right now, first create a firewall rule, see above, where there is no new state, and then connect IPsec and create an IPIP tunnel, and I got the status ready, where is the new state?
I’m really sorry, and I don’t mean it in any sort of dismissive way, but I simply don’t believe you. Something is going on that you’re not telling. Show me!
First, run
/ip firewall filter export
Note down the counter for your “drop” rule.
ection
Then
/ip firewall connection print where protocol=4
Now try the connection.
Note down your “drop” counter again.
Because it works for me.
I have no established ipip connections:
[admin@xxx] > /ip firewall connection print where protocol=4
(nothing)
I have an established/related rule followed by a drop protocol 4:
15 ;;; established
chain=input action=accept connection-state=established,related log=no log-prefix=""
16 ;;; drop proto 4
chain=input action=drop protocol=ipencap log=no log-prefix=""
The remote side is configured with a 10s keepalive. Counters are increasing:
[admin@xxx] > :put [ /ip firewall filter get 16 packets ]
0
(...about a minute later...)
[admin@xxx] > :put [ /ip firewall filter get 16 packets ]
4
The ipip interface on the remote end is shown as not running:
[admin@xxx2] > /interface/ipip/print proplist=name,running
Columns: NAME, RUNNING
# NAME RUNNING
0 ipip-tunnel1 no
maybe you are wrong, because I don’t see your whole configuration,
the problem is that having two hosts on the internet, the only way I get to avoid leaking an unencrypted tunnel is to apply
/ip firewall filter add action=drop chain=input ipsec-policy=in,none protocol=ipencap place-before=0
before established,related, if for example, the ipsec tunnel can be broken, and one of the hosts works with port-strict policies
this is very inconvenient behavior
Well, there’s always a chance I’m wrong. I think it’s fairly clear that a keepalive is sent every 10s, and the keepalives are dropped.
The example you’ve screenshotted with the CHRs will obviously not work. This is because both sides are configured for keepalive by default. This means that both sides send keepalives to each other.
When an initial keepalive is sent, it’s state is “new”. This packet is not filtered in the output chain of the router sending it, so a conntrack entry is created. (Of course it’s filtered on the other end’s input chain.) But the other end also sends keepalives, which results in the conntrack entry being created ultimately on both ends.
This is why if you look at the list of connections (as suggested), you will find an IPIP connection to the other side in the “established” state, and why the firewall accordingly allows it.
EDIT: I also fail to see how this is a significant inconvenience. It’s fully proper to configure the firewall as you propose, i.e. drop packets before the sllow established/related rule. (And there are numerous other suitable ways to drop unencrypted packets inside or outside the firewall, including discard policies.)