Hello My friends…!
so please if anyone of you have a deep understanding of Masqurade rule in general if he/she can explain to me this yellow bar ..!?
they said that if a primary link comes back, routing is restored over primary link…etc so in this case i dont see any different between masqurade rule and srcnat rule.?
the same thing will happen if we used a srcnat rule..?
any suggestion..!?
second i didnt understand what they actually mean by leaking local IPs to a public network. i heard about leaking public address but what about leaking local address..?
there is a difference between masquerade and src-nat..
Masquerade will mask any (dynamic) public you have… so if you are changing your public ip once in 10 seconds, masquerade will follow..
src nat is bound to single public ip…
One of the best source for the background details is an older MUM presentation by Mikrotik, “My ‘holy war’ against masquerade”:
(or video here: https://www.youtube.com/watch?v=3LmQYIQ5RoA&list=PLXr-HoBo2VtU07_O_h_uGe3QOe2lg74Vx&index=2 )
[and they improved the default firewall since the pdf/video… but used to be able to “leak” & that’s explained in older presentation – BUT why the newer firewall defaults include a “drop invalid” in the firewall filter, ending the ‘holy war’]
Do you mean in the input chain or forward chain???
Re Docs suggest and QuickSet adds it, https://help.mikrotik.com/docs/display/ROS/Building+Your+First+Firewall etc :
add action=drop chain=forward comment="Drop invalid" connection-state=invalid log=yes log-prefix=invalid
As some point the defaults didn’t do that, and yes packet would leak out in the small amount of time while the routing table failover from say WAN1 to WAN2.
This was especially noticeable with Verizon and LTE years ago, one packet that leaks out, Verizon drops the connection. So always added based on the video, but been in default for a long while.
@amm0 Considering 67 mass shooting in the US in 2023 ( more than one a day ) suggest its time to change the bullet to something more palatable like a nice soft white balloon. ;-PP
Tell it to Nintendo’s Mario Kart. The preferred noun is AmmØ – but forum [usernames] and RouterOS doesn’t support unicode.
AmmØ, thanks for the interesting background regarding the issue when the connection table is flushed and why you still need to drop all packets with connection-state=invalid.
Hello Mr Amm0..! please in the video above that you already mentioned to it, can you explain to me this section -(from 23:10m to 24:10)- i didnt nderstand what he want to elaborate..!?
he said that NAT has already work on the connection and those packet will just ….etc.
then he said but masqurade rule purged the connection, so if that happen why we have such this issue -(leaking our local IP to the external network )- ..? when the primary link comes back why the first packet must came as a new coonection..!
is that right..!?
The most important feature of masquerade (as compared to “normal” SRC NAT) is “WAN link state awareness”. Meaning that if WAN link goes down, masquerade prepares for WAN IP address change (which is what often happens). And preparation for IP address change includes tearing down all connections … obviously firewall on router can’t set connection as dropped on any of connection endpoint (client, server), firewall would have to send RST packets to both sides and it can’t do it for one side because link to that side just dropped. But it does clear own connection tracking table. And from this point forward any TCP packet, not being the first of TCP connection establishment handshake (payload-less packet with SYN flag set), is deemed as invalid (and thus dropped unless firewall filter rules are flawed).
With “normal” SRC NAT the above doesn’t happen. Which means that when WAN address is static, most (if not all) connections will resume after a pause (if the pause is shorter than TCP retransmission timeouts and/or application timeouts). However, if WAN address changes, all of ongoing connections will drop because address used by SRC NAT won’t belong to router any more and return packets won’t reach it.