/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=fasttrack-connection chain=forward
what do you think about this 3 rules on the top of the firewall? If I dont put fasttrack my cpu goes to 50,60%. It is ccr 1008.
First two rules are for input chain, the 3rd, fasttrack is for forward chain and has nothing to do with first 2 rules.
Also not sure I understand your question?
my q was, does it something thats a MUST HAVE this input chain rules to have most of the benefits of the firewall. Is there some updated firewall rules for preventing intrusions?Maybe someone to share their firewall without sensitive data ofc
Short answer: yes, it is a must have.
Long answer:
Fasttracking means that packets belonging to existing connections bypass
So if fasttracking rule lowers the CPU load significantly, something in the above list is causing the CPU load.
Without fasttracking, the action=accept connection-state=established,related,untracked accepts the part of forwarded traffic which would otherwise be accepted due to fasttracking. Only initial packets of forwarded connections will make it past this rule to the subsequent filter ones; these subsequent rules decide which connections will be permitted and which will not.
If connection tracking is active, every single packet is compared to the complete list of existing connections. And if it matches any already existing one, it is labeled with connection-state “established”, and the rule you mention accepts it (or fasttracking accepts it instead if enabled).
The connection tracking itself is also quite CPU intensive, and fasttracking makes no sense in input chain. So as in your case, a lot of traffic is probably IPsec one, you could use
chain=prerouting dst-address-type=local protocol=udp dst-port=500,4500 action=notrack
chain=prerouting dst-address-type=local protocol=ipsec-esp action=notrack
chain=output protocol=udp src-port=500,4500 action=notrack
chain=output protocol=ipsec-esp action=notrack
rules in /ip firewall raw to prevent IPsec packets to and from your router itself from being connection-tracked. The same rule in filter will accept them as it matches also on connection-state “untracked”, but the amount of CPU spent on those raw rules may be lower than the one otherwise spent by connection-tracking on the same packets. The actual benefit of this depends on the amount of tracked connections in total.
If you eventually don’t need to use the router as a firewall for forwarded traffic, you may stop using connection tracking at all and only use rules in input chain to protect the router itself. Connection tracking is common for all traffic (both local and forwarded), so stopping to refer to connection-state and connection-nat-state only in input chain of filter will not help lower the CPU load. But in that case, the order of the rules in the filter is very important - most packets should pass through the least number of rules, so accept rules for the most frequent packets must be at the top of the list (probably ipsec-esp).
Why dont you ask the real question which is.
I don’t have a sweet effing clue about what the MT firewall rules do or mean, so can somebody please explain them.!
(which is basically the question Sindy answered because he is a very kind man and wicked smart).
So you think this is the best rules to put it on top
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=fasttrack-connection chain=forward
and add this ti raw
add action=notrack chain=prerouting dst-address-type=local dst-port=500,4500 protocol=udp
add action=notrack chain=prerouting dst-address-type=local protocol=ipsec-esp
add action=notrack chain=output protocol=udp src-port=500,4500
add action=notrack chain=output protocol=ipsec-esp
There is no such thing as “the top of filter”. There is the top of chain input in filter, and there is the top of chain forward in filter. Packets always only go through one of these rule chains, not both.
So the default firewall of the SOHO grade devices is the optimum one:
add action=accept chain=input connection-state=established,related,untracked
add action=drop chain=input connection-state=invalid
… individual permissive rules if necessary for IPsec and other VPNs and/or for direct remote management via secure protocols…
add action=drop chain=input in-interface-list=WAN
If you don’t want to permit access to router management from anywhere in the LAN, add permissive rules for authorized LAN devices where indicated and remove the in-interface-list=WAN from the last rule in input.
Adding the rules I’ve suggested to raw may reduce the CPU load. You have to try, it depends on your traffic structure whether the difference will be noticeable or not.
In forward, the structure is basically the same, except that the action=fasttrack-connection rule must be followed by action=accept chain=forward connection-state=established,related,untracked because some small amount of packets belonging to fasttracked connections takes the full path through the firewall, and if you use bare IPsec with policy matching, it must be preceded by action=accept chain=forward connection-state=established,related,untracked ipsec-policy=in,ipsec and action=accept chain=forward connection-state=established,related,untracked ipsec-policy=out,ipsec as connections which need to be handled by IPsec policies must not get fasttracked. In special cases, these rules exempting connections from fasttracking have to be more complex (where NAT is necessary in order that the packet matched the IPsec policy, it doesn’t match the ipsec-policy=in|out,ipsec while being handled in filter), so you need to use src-address(-list) and dst-address(-list) matching, connection-mark matching etc. there.
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked disabled=yes
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid disabled=yes
add action=accept chain=forward comment="defconf: accept established,related,untracked" connection-state=established,related,untracked disabled=yes
add action=fasttrack-connection chain=forward disabled=yes
add action=accept chain=forward dst-address=10.11.0.0/16 src-address=192.168.30.0/24
add action=accept chain=input dst-address=10.11.0.0/16 src-address=192.168.30.0/24
add action=drop chain=forward comment="Drop Inv." connection-state=invalid
add action=accept chain=forward dst-address=10.98.0.0/24 src-address=192.168.2.0/24
add action=accept chain=input in-interface=vrrp_WAN1 protocol=icmp
add action=accept chain=input comment="permit from local ip DNS reuqest udp 53" dst-port=53 protocol=udp src-address-list=local_ip
add action=accept chain=forward dst-address=192.168.200.0/24 src-address=192.168.23.0/24
add action=accept chain=forward dst-address=192.168.200.0/24 src-address=172.16.2.0/24
add action=accept chain=forward dst-address=192.168.200.0/24 src-address=192.168.30.0/24
add action=reject chain=input comment="Drop !DNS" dst-port=53 protocol=udp reject-with=icmp-network-unreachable
add action=reject chain=input comment="Drop !DNS" dst-port=53 protocol=tcp reject-with=icmp-network-unreachable
add action=accept chain=input comment=SSH dst-port=4777 protocol=tcp src-address-list=HQ2Addresses
add action=accept chain=input comment=SSH dst-port=4777 protocol=tcp src-address-list=HQ1Addresses
add action=accept chain=input comment=WinBox dst-port=8291 protocol=tcp src-address-list=HQ1Addresses
add action=accept chain=input comment=WinBox dst-port=8291 protocol=tcp src-address-list=HQ2Addresses
add action=accept chain=input comment="Allow ICMP" protocol=icmp src-address-list=HQ2Addresses
add action=accept chain=input comment="Allow ICMP" protocol=icmp src-address-list=HQ1Addresses
add action=drop chain=input comment="Drop Inv." connection-state=invalid
add action=reject chain=input comment="Drop !DNS" dst-port=53 protocol=tcp reject-with=icmp-network-unreachable src-address-list=!DNS
add action=reject chain=input comment="Drop !DNS" dst-port=53 protocol=udp reject-with=icmp-network-unreachable src-address-list=!DNS
add action=accept chain=output comment="OUT PMTUD" icmp-options=3:4 protocol=icmp
add action=accept chain=input comment="IN PMTUD" icmp-options=3:4 protocol=icmp
add action=accept chain=input comment="IN-Allow ping 1468b up to 5 in sec" limit=5,1:packet packet-size=1468 protocol=icmp
add action=add-src-to-address-list address-list=pingers address-list-timeout=1d chain=input comment="IN-List ICMP which dont match criteria" dst-address-list=!HQ1Addresses in-interface-list=WAN log-prefix=Ping@IN protocol=icmp src-address-list=\
!HQ1Addresses
add action=add-src-to-address-list address-list=@Services_Phase1 address-list-timeout=30m chain=input comment=IN-Services_Phase1 dst-address-list=!HQ1Addresses dst-port=21,22,23,69,80,443,5060,8080 in-interface-list=WAN protocol=tcp src-address-list=\
!HQ1Addresses
add action=add-src-to-address-list address-list=@Services_Phase1 address-list-timeout=30m chain=input comment=IN-Services_Phase1-UDP dst-address-list=!HQ1Addresses dst-port=21,22,23,69,80,443,5060,8080 in-interface-list=WAN protocol=udp src-address-list=\
!HQ1Addresses
add action=add-src-to-address-list address-list=@Services_Phase2 address-list-timeout=30m chain=input comment=IN-Services_Phase2 dst-port=21,22,23,69,80,443,5060,8080 in-interface-list=WAN protocol=tcp src-address-list=@Services_Phase1
add action=add-src-to-address-list address-list=@Services_Phase2 address-list-timeout=30m chain=input comment=IN-Services_Phase2-UDP dst-port=21,22,23,69,80,443,5060,8080 in-interface-list=WAN protocol=udp src-address-list=@Services_Phase1
add action=add-src-to-address-list address-list=@Services_Phase3 address-list-timeout=1w chain=input comment=IN-Services_Phase3 dst-port=21,22,23,69,80,443,5060,8080 in-interface-list=WAN protocol=tcp src-address-list=@Services_Phase2
add action=add-src-to-address-list address-list=@Services_Phase3 address-list-timeout=1w chain=input comment=IN-Services_Phase3-UDP dst-port=21,22,23,69,80,443,5060,8080 in-interface-list=WAN protocol=udp src-address-list=@Services_Phase2
add action=drop chain=input comment=IN-Phase3_dropRAW src-address-list=@Services_Phase3
add action=drop chain=input comment="IN-Block Shodan" src-address-list=shodan
add action=drop chain=input comment="IN-Defend from pingers" src-address-list=pingers
add action=accept chain=input dst-port=161 protocol=udp
add action=accept chain=forward dst-port=161 protocol=udp
add action=accept chain=output dst-port=161 protocol=ud
Gluck with that bloated mess Sindy. 
I have explained this in the previous post, which you’ve quoted as a whole (no idea why you do that) but apparently haven’t read or understood it.
The connections transported using IPsec must not get fasttracked. As your current action=fasttrack-connection rule matches on all forwarded traffic, it prevents Dude requests from being forwarded to destinations accessible via IPsec, and prevents responses from devices which are accessible without IPsec from being delivered back to the Dude.
You have to prevent traffic which needs to be transported using IPsec from matching that rule, or from even reaching it. I’ve told you how to do that - by placing rules that accept packets beloging to both directions of that traffic in filter before these packets reach the action=fasttrack-connection rule.
But with the fasttrack rule fasttracking only what it should, the CPU load may not decrease too much, as the difference in CPU load with the fasttracking rule disabled and enabled may be caused by the fact that part of the traffic simply doesn’t exist - if the requests don’t reach the destination, there are no responses, and if the initial query doesn’t succeed, the subsequent ones are not sent at all. So the actual decrease of CPU load depends on the ratio between the traffic transported using IPsec and the traffic which doesn’t need IPsec.
Another noteworthy point is that the firewall rules you currently have in filter chain forward effectively do nothing, because the traffic which doesn’t match to any of the rules gets accepted. The rules in output chain are the same case - everything the router sends out is sent, but each packet is inspected by two rules.
is this better? i missread the ipsec in and out in forward.
first i add mangle to capture ipsec, router is now at 25,30%
/ip firewall mangle add action=mark-connection chain=forward comment="mark ipsec connections" ipsec-policy=out,ipsec new-connection-mark=ipsec
/ip firewall mangle add action=mark-connection chain=forward comment="mark ipsec connections" ipsec-policy=in,ipsec new-connection-mark=ipsec
than do what i think you told me
/ip firewall filter
/ip firewall filter
add action=fasttrack-connection chain=forward connection-mark=!ipsec connection-state=established,related
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
because the traffic which doesn’t match to any of the rules gets accepted
how to fix it? just to add drop rule?
Yes, this is yet another way how to do that. With this setup, a packet transported using IPsec is inspected by 1.5 mangle rule on average (those matching on ipsec-policy=out,ipsec are handled by one, those matching on ipsec-policy=in,ipsec are handled by two). You can reduce that to a single rule for each direction by placing action=accept chain=forward connection-state=!new before them in mangle. It is sufficient to assign the connection-mark to the connection when handling its initial packet, so all subsequent packets of the same connection don’t need to be inspected for a match on the ipsec-policy again. So all mid-connection packets will match already on the connection-state=!new.
Yes. Plus you may want to place an action=log rule before the action=drop one to see what the drop one drops. It will help you notice which “legal” traffic you forgot to permit, and what is the illegal traffic trying to get through your router.
i added that firewall mangle rule before those ipsec.
I got aproblem that tunnels goes down, msg1 sent error and i must disable all that i newly created and restart peer and than tunnels go up.
Yes
you think about these 3 rules that dont have a drop one? i cant see any other from my post under.
I can’t get how a rule in forward chain of mangle should break IPsec transport and control traffic which is handled by chains input and output. Post the export of the mangle.
Yes
2020-11-01 14_47_00-Window.png
you think about these 3 rules that dont have a drop one? i cant see any other from my post under.
[/quote]
I was talking about adding the “drop the rest” rule solely to chain forward in filter. If you’ve added a “drop the rest” rule also to chain output in flter, there’s no wonder it has broken the tunnels. A drop in output of filter is only used for very specific purposes. Regarding chain input of filter, I didn’t dive deep into what you’ve set up there.
I was talking about adding the “drop the rest” rule solely to chain forward in filter. If you’ve added a “drop the rest” rule also to chain output in flter, there’s no wonder it has broken the tunnels. A drop in output of filter is only used for very specific purposes. Regarding chain input of filter, I didn’t dive deep into what you’ve set up there.
[/quote]
This is mangle now
/ip firewall mangle
add action=mark-packet chain=forward new-packet-mark=VOIP passthrough=yes \
src-address=VOIP
add action=mark-packet chain=forward dst-address=VOIP new-packet-mark=\
VOIP passthrough=yes
add action=mark-packet chain=prerouting comment=office-subnet dst-address-list=\
!VIDEO new-packet-mark=Marketing passthrough=yes src-address-list=\
ISP2
add action=mark-routing chain=prerouting comment=office-subnet dst-address-list=\
!VIDEO new-routing-mark=Marketing packet-mark=Marketing passthrough=\
yes src-address-list=ISP2
add action=mark-connection chain=prerouting comment=Raspberry connection-mark=\
no-mark disabled=yes new-connection-mark=raspTemp passthrough=yes \
src-address=192.168.50.144
add action=mark-routing chain=prerouting comment=Raspberry connection-mark=\
raspTemp disabled=yes new-routing-mark=raspTemp passthrough=yes \
src-address=192.168.50.144
add action=mark-connection chain=prerouting connection-mark=no-mark dst-port=53 \
layer7-protocol=*4 new-connection-mark=block_connection passthrough=yes \
protocol=udp
add action=mark-packet chain=prerouting connection-mark=block_connection \
new-packet-mark=block_packet
add action=accept chain=forward connection-state=!new disabled=yes
add action=mark-connection chain=forward comment="mark ipsec connections" \
disabled=yes ipsec-policy=out,ipsec new-connection-mark=ipsec passthrough=\
yes
add action=mark-connection chain=forward comment="mark ipsec connections" \
disabled=yes ipsec-policy=in,ipsec new-connection-mark=ipsec passthrough=\
yes
any drop that i have is
0 X ;;; defconf: drop invalid
chain=forward action=drop connection-state=invalid log=no log-prefix=""
1 X ;;; defconf: drop invalid
chain=input action=drop connection-state=invalid log=no log-prefix=""
2 ;;; @Dongla Server drop Locations
chain=forward action=drop src-address=192.168.50.144
dst-address=10.0.0.0/8 log=no log-prefix=""
3 X chain=forward action=drop protocol=icmp packet-size=200-65535 log=no
log-prefix=""
4 ;;; Drop Inv.
chain=forward action=drop connection-state=invalid
5 ;;; Drop Inv.
chain=input action=drop connection-state=invalid
6 ;;; IN-Phase_dropRAW
chain=input action=drop src-address-list=@Servisi_Phase log=no
log-prefix=""
7 ;;; IN-Block shodan
chain=input action=drop src-address-list=shodan
8 ;;; IN-Defend from pingers
chain=input action=drop src-address-list=pingers log=no log-prefix=""
I have posted in thread tunnel troubleshot a log and ip ipsec installed-sa print results at the time tunnel dont work. But what is strange.
I have LAN subnet which are all created by MikroTik and anothers which are on the Cisco L3, maybe the drawing make you easier to understand.
So, subnets which are creating a tunnel is maked on mikrotik and on cisco. And someday one have a problem and not the another, and so on. Then, one subnet for example 192.168.50.0/24 dont see 10.11.0.0/16 even if status is established and have access to 10.10.0.0/16, and so on.
There are more ipsec and on the other side there is some directly connected subnets (not all are openvpn, some is directly connected to pfsense).
10.10.0.0/16 and 10.11.0.0/16 are remote locations not phisically in the building where is pfsense
Let’s keep the threads (firewall and IPsec) separate.
Here, try to enable only the three mangle rules you’ve added, but keep those drop ones, which you’ve eventually added since the point in time when it was working, disabled, and tell me how it works.
i cant enable JUST those three in mangle, because here i mangle some subnet and force it to another ISP in routes and also using for VOIP, so i cant disable it.
I had in mind “out of the rules added by my recommendation, enable only the three added to mangle, not the drop ones in filter”. Of course all your pre-existing rules must stay in place.
Also, from your print of drop rules, it seemed to me that the drop one in forward in filter was not the very last one in that chain. The rules are matched in sequence, first towards last until first match to a rule providing a final verdict, in the chain chosen depending on packet type: incoming to router itself, i.e. no out-interface used / forwarded from interface to interface / outgoing from router itself, i.e. no in-interface used.
it is how it was earlier, i just added that three in mangle if you think about these rules
add action=accept chain=forward connection-state=!new disabled=yes
add action=mark-connection chain=forward comment="mark ipsec connections" \
disabled=yes ipsec-policy=out,ipsec new-connection-mark=ipsec passthrough=\
yes
add action=mark-connection chain=forward comment="mark ipsec connections" \
disabled=yes ipsec-policy=in,ipsec new-connection-mark=ipsec passthrough=\
yes
and you saw drop rules in filter, dont sure what you point, i have the rule number four same as number one, and i will remove it.
;;; Drop Inv.
chain=forward action=drop connection-state=invalid