I am unsure how to deal with firewall BOGON rules in topology. MT wiki suggests dropping connections to or from BOGON addresses and must masquerade LAN network with srcnat NAT rule.
The problem is dropping BOGON crossing the WAN interface blocks LAN network even with NAT srcnat masquerading.
I can see in log the rules dropping forwarded TCP SYN packets from LAN 192.168.1.0/24. This is why LAN internet is blocked. Rule is dropping NEW connection state attempts.
My question is why does rule block LAN? Why doesn't firewall allow when LAN is masqueraded?
What MT suggests that deviates from the defaults is very questionable IMHO. Most folks dont need any additional rules. If there are legit concerns to nail down the setup then by all means.
/export file=anynameyouwish (minus router serial number, any public WANIP information, keys etc.)
You are using an article on the old Wiki. Not only MikroTik staff but other users could also write articles on that Wiki and the article in question is not from MikroTik but from some random guy.
Here is the current official firewall example from MikroTik:
Please note that not everything mentioned in the new article is relevant and recommended. For example, all those RAW rules can be ignored.
As for the reason why what you posted above doesn't work and cause problem: Study this flowchart of the MikroTik firewall:
You can see that srcnat happens at the end of the flowchart, on step #25. Which means for the first packets of a new connection being forwarded, when the filter rules are checked on those packets on step #14, there is absolutely no information that the connection will be SRCNATed yet. Which means your check for connection-nat-state=!srcnat always yields true and considered "matched". Thus, packets of a new connection from LAN to WAN will all match the action=drop rule because all conditions are true (src-address-list, out-interface-list, and connection-nat-state=!srcnat).
My recommendation is to undo whatever that questionable Wiki page suggested (the whole SYN flood and port scan checks are frankly useless), go back to the defconf firewall or implement what suggested in the new documentation (minus RAW rules).
Yes, did some testing and spotted it after using a combination of mangle forward to mark packets plus mangle postrouting rule and mangle forward with the inverse of the packet marking one, then logging to see differences and was able to spot the srcnat mark doesn't exist until after postrouting so the forward filter to drop BOGONs isn't matching because the srcnat doesn't exist.
As we can only drop on filter rules and not in mangle phase, is there a low-CPU intensive way to drop BOGONs while excluding some subset of BOGONs before the packets have a srcnat identifier?
Maybe I need to revise my logic.
The guidance suggests disabling RFC1918 address in BOGON list if you rely on it for LAN, but I don't want to do this because of possibility of leaking internal IP if firewall rules not designed well. To me it is safer/better to keep RFC1918 in BOGON list and have a firewall forward rule drop before forwarding out of WAN if forwarded traffic is not related to srcnat. So the problem is to try to identify/mark pre-srcnat traffic to exclude it from drop rule.
I'm not sure what you're trying to accomplish. To be blunt (sorry in advance) I'm not sure you're sure what you want to accomplish.
When I want to do source address validation (which dropping in BOGONS is a part of) I usually use rules that match both in-interface(-list) and src-address(-list), so vaguely of this form:
Since these rules generally apply to packets both in the forward and input chains, it's usual to put them in a custom chain and add a jump to them in both.
In addition to what @lurker888 already wrote above, I would like to address this claim from yours: assuming that you have a standard SRCNAT masquerade rule that acts on out-interface-list=WAN, then there is no possible leaking of internal LAN addresses in src-address anymore, because the source addresses would have been replaced already before leaving the interface into the WAN side.
If, however, you don't have a standard masquerade rule, but have many additional conditions beside out-interface-list=WAN before masquerading, then you can create a filter chain forward & output action=accept rule with exactly those same conditions (plus out-interface-list=WAN), and place that rule before the filter rules that block bogons that you have above. Assuming those bogon rules are at the bottom of the filter list. That way you can exclude those "legitimate" packets from being dropped.
(If the bogon drop rules are not at the bottom of the filter rules, then you'll probably don't want to add accept rules, but modify those bogons rule and add negated conditions, the reverse of the additional conditions that you added to the masquerade rule instead.)
Just to add to the remarks by @CGGXANNX about my comment (recursion: see recursion), in the very edge case where you need a combination of very selective srcnat rules and want to be absolutely certain that you don't leak internal addresses, you would want to do the following. Just to be VERY clear: this is not something that you should be doing or be proud of, but...
add chain=srcnat action=drop out-interface=my_wan
Now, this doesn't work. The traditional iptables era netfilter isn't willing to drop packets in nat postrouting and the userspace-side iptables gives the following error:
The "nat" table is not intended for filtering, the use of DROP is therefore inhibited.
Try `iptables -h' or 'iptables --help' for more information.
So, with regard to this, you're running into the architectural limitations of the version of the interface to netfilter currently used by Mikrotik.
If you are adamant about never leaking an internal source address, it's still possible (even under the old iptables-based interface to netfilter) to add a final srcnat rule to change the source address to something not very distinguished, like 0.0.0.0.