I’m configuring IPSec site-to-site tunnel in demo environment using this wiki: https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Site_to_Site_IPsec_tunnel
I have two CHR 6.46.7 on Hyper-V. Each CHR have only two interfaces - LAN and WAN. First CHR LAN IP is 192.168.1.1, second CHR LAN IP is 192.168.2.1
I created NAT bypass rules (like in wiki’s example). I don’t use fastTrack bypass rules - because CHR don’t support fastTrack.
But I can’t ping 192.168.2.2 workstation from 192.168.1.2 workstation
Basic firewall blocks this pings (last rule for forward). But Wiki don’t give example rules for forwarding traffic.
Is Wiki’s excample incomplete, and I need additional firewall rules for forward traffic?
My firewall config:
[admin@MikroTik] > ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; Accept - established, related
chain=input action=accept connection-state=established,related log=no log-prefix=“”
1 ;;; Drop - invalid
chain=input action=drop connection-state=invalid log=no log-prefix=“”
7 ;;; Drop - invalid
chain=forward action=drop connection-state=invalid log=no log-prefix=“”
8 ;;; Drop - new from wan not dstnat-ted
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN log=yes
log-prefix=“”
[admin@MikroTik] >
[admin@MikroTik] > ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=srcnat action=accept src-address=192.168.2.0/24 dst-address=192.168.1.0/24 log=no log-prefix=“”
What made you think this? Fasttrack means that most of firewall handling and some other stages of packet handling are skipped, so it is not a pure hardware bypass, it is a software one as well and thus it makes sense also on a CHR and is available there. EDIT: see further posts.
I wouldn’t say it is incomplete. It’s just nothing more and nothing less than an example for a typical use case. If your use case differs from the one covered by the example, you have to modify the example configuration accordingly, you cannot just leave out what you assume is not necessary.
The example contains one possible type of additional firewall/filter rules used to avoid fasttracking the connections which need to be transported using IPsec, but the thing is that these rules also act as permissive ones for this traffic.
The in-interface property of packets which have arrived encapsulated in IPsec transport ones is inherited from the transport ones, so the packet from 192.168.1.2 is treated as if coming from WAN, hence the rule
8 ;;; Drop - new from wan not dstnat-ted
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN log=yes
log-prefix=""
drops it.
There are multiple ways how to solve this. The simplest one is to make the rule above match only on packets which do not mirror-match any IPsec policy, by adding ipsec-policy=in,none to its condition list.
OK, so I was wrong - before posting, I’ve checked that CHR supports fasttracking in terms that it can be configured and connections do get the F mark, but it didn’t come to my mind that it might actually do nothing, so there is no point in using it. Bypassing those stages of packet handling would save some CPU even on the CHR, but apparently Mikrotik assumes that it is not worth it.
I don’t use FastTrack rule in my lab environment, so I don’t use FastTrack bypass rules.
About
There are multiple ways how to solve this. The simplest one is to make the rule above match only on packets which do not mirror-match any IPsec policy, by adding ipsec-policy=in,none to its condition list.
With ipsec-policy=in,none ping works. But this rule completely permits all traffic between lan1 and lan2?
Yes. If you want more selective rules, place them before that “drop whatever comes from WAN and is not dst-nated” one, as action=accept ones, instead of modifying that one. Also there, if you e.g. want to permit access to some local destination address and port for anyone from the remote LAN, you can use matching on in-interface-list=WAN ipsec-policy=in,ipsec.
9 ;;; Drop - new from wan not dstnat-ted
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN log=yes
log-prefix=“”
[admin@MikroTik] >
[admin@MikroTik] > ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=srcnat action=accept src-address=192.168.2.0/24 dst-address=192.168.1.0/24 log=no log-prefix=“”