6.30 ipsec-policy matcher question

RouterOS General
1

Hi guys,

Whats the difference between ipsec-policy=in,ipsec and ipsec-policy=in,none?

Its not made clear in the new Manual article
http://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Allow_Only_Ipsec_Ecapsulated_Traffic

Also the options are not yet described in the firewall Manual article
http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter

Thanks!

2

Now added to fw manual. There you will find difference between ipsec and none

3

Just a final confirmation, so basically the settings are:

ipsec-policy=in,none - incoming packets matched by any policy before decryption
ipsec-policy=in,ipsec- incoming packets matched by any policy after decryption

ipsec-policy=out,none - outgoing packets matched by any policy after encryption
ipsec-policy=out,ipsec- outgoing packets matched by any policy before encryption

4

I also would like to be sure I understand IPsec-policy match…so if I have a firewall rule as:
input chain > advanced >IPsec-policy: in/none >Protocol: 50 (ipsec-ESP) >Action: Accept
Then that would place restrictions and add security enhancement through policy matching? I want to learn as much as I can to make my VPN very secure.

5

Well, I tried the above as well as advanced >IPsec-policy: in/ipsec and both worked okay…so, I left it with advanced >IPsec-policy: in/ipsec…matches if the packet is subject to IPsec processing! Still trying to make sense of it and hope either of the other parties that responded to the post shed some more light.

6

Yes, exactly.

7

I could also do with some extra assistance / documentation on using this feature, it looks useful!

8

I agree and would like further explanation…for instance, advantage of ipsec-policy >in/none VS ipsec-policy >in/ipsec although, intuitively, ipsec-policy >in/none seems to have an edge since it checks if a policy matches before decryption…still, the subject leaves one in the dark somewhat. Why…because L2TP would not have given out a LAN IP address yet.

9

It looks as if the IPsec-policy matcher in 6.47 is broken: ipsec-policy=in,none matches all incoming packets even if no any ipsec policies are defined.

Repro-case:

/ip firewall filter add chain=input ipsec-policy=in,none action=log log-prefix="ipsec-policy matched test"

make this rule first in the chain and see log - all incoming traffic is logged.

But the matcher must validate packets against defined ipsec policies, isn’t it? At least exactly this behavior is declared and expected. Could you, please, check and clarify?

Thank you a lot.

10

It is true (and I think it is correct) that ipsec-policy=in,none matches all traffic that is NOT protected by IPsec, and ipsec-policy=in,ipsec matches all traffic that IS protected by IPsec.
At least, that is how I always used it. Like this:

add action=accept chain=input-inet comment=L2TP/IPsec dst-port=1701 \
    ipsec-policy=in,ipsec protocol=udp
add action=reject chain=input-inet comment="L2TP no IPsec" dst-port=1701 \
    ipsec-policy=in,none log=yes log-prefix=l2tp protocol=udp reject-with=\
    icmp-port-unreachable
11

Exactly, ipsec-policy=in,none means packets with no IPSec policy defined for them. If no policy exists, it’s true for all packets.

12

2 Sob:

If no policy exists, it’s true for all packets

none doesn’t match ipsec-policies even if they are defined

2 pe1chl:

I checked your example. It works the same with no ipsec-policy=in,none in the second rule:

add action=accept chain=input-inet comment=L2TP/IPsec dst-port=1701 \
    ipsec-policy=in,ipsec protocol=udp
add action=reject chain=input-inet comment="L2TP no IPsec" dst-port=1701 \
    log=yes log-prefix=l2tp protocol=udp reject-with=\
    icmp-port-unreachable

But in other order of rules - it is required, with no ipsec-policy=in,none in the fist rule, the example doesn’t work as expected.

add action=reject chain=input-inet comment="L2TP no IPsec" dst-port=1701 \
    ipsec-policy=in,none log=yes log-prefix=l2tp protocol=udp reject-with=\
    icmp-port-unreachable
add action=accept chain=input-inet comment=L2TP/IPsec dst-port=1701 \
    ipsec-policy=in,ipsec protocol=udp

Hm… MRZ confirmed in this thread:

ipsec-policy=in,none - incoming packets matched by any policy before decryption
ipsec-policy=in,ipsec- incoming packets matched by any policy after decryption

ipsec-policy=out,none - outgoing packets matched by any policy after encryption
ipsec-policy=out,ipsec- outgoing packets matched by any policy before encryption

is it incorrect? Must it be:

ipsec-policy=in,none - any incoming packets exclude decrypted IPsec
ipsec-policy=in,ipsec- incoming packets matched by any policy after decryption

ipsec-policy=out,none - any outgoing packets exclude decrypted IPsec
ipsec-policy=out,ipsec- outgoing packets matched by any policy before encryption
13

It’s true that the wording is confusing. Manual has better description:

ipsec-policy (in | out, ipsec | none; Default: )

Matches the policy used by IpSec. Value is written in following format: direction, policy. Direction is Used to select whether to match the policy used for decapsulation or the policy that will be used for encapsulation.

in - valid in the PREROUTING, INPUT and FORWARD chains
out - valid in the POSTROUTING, OUTPUT and FORWARD chains

ipsec - matches if the packet is subject to IpSec processing;
none - matches packet that is not subject to IpSec processing (for example, IpSec transport packet).

For example, if router receives Ipsec encapsulated Gre packet, then rule ipsec-policy=in,ipsec will match Gre packet, but rule ipsec-policy=in,none will match ESP packet.