I do have an understanding problem with what happens when WAN interfaces are swapped and masquerading is active.
In particular, how the connection remains active when routing is restored over the primary link (primary WAN interface) after it was routed via the backup route (backup WAN interface)
In NAT - RouterOS - MikroTik Documentation it is stated:
In addition, in Most underused and overused RouterOS features. My holy war against masquerade MUM, USA it is said the same in short:Masquerade
... it was designed for specific use in situations when public IP can randomly change,...
Unfortunately, this can lead to some issues with unstable links when the connection gets routed over different links after the primary link goes down. In such a scenario following things can happen:
To work around this situation blackhole route can be created as an alternative to the route that might disappear on disconnect.
- on disconnect, all related connection tracking entries are purged;
- next packet from every purged (previously masqueraded) connection will come into firewall as new, and, if a primary interface is not back, a packetwill be routed out via alternative route (if you have any) thus creating a new masqueraded connection;
- the primary link comes back, routing is restored over the primary link, so packets that belong to existing connections are sent over the primary interface without being masqueraded, that way leaking local IPs to a public network.
...
overcome limitations RouterOS includes a number of so-called NAT helpers, that enable NAT traversal for various protocols. When action=srcnat is used instead, connection tracking entries remain and connections can simply resume.
but nowhere is said, why the established is:
- On disconnect, all related connection tracking entries are purged
- Next packet from every purged connection will come into firewall as connection-state=new, and, packet will be routed out via alternative route thus creating new connection entry
- When primary link comes back, routing is restored over primary link, so packets that belong to existing connections are sent over primary interface without being masqueraded
- switch back to the primary link
- why the connection is not interrupted (remains ESTABLISHED during this process as the route changes
- why these mysterious NAT helpers don't make it appear as a NEW connection to connection-tracking
MY QUESTIONS, A&B:
- I'm struggling to describe the entire process, may someone can complete it, this is what I have:
- the route through ETHER1 closed --> all connections through ETHER1 are purged from connection-tracking (CT)
Traffic is routed through a different interface if there is one. - ETHER2 is the backup route, so traffic goes now through ETHER2, being tracked again and masquerade.
This is because the connection was interrupted and has to be rebuilt, so CT lists the traffic as NEW and then ESTABLISHED from LAN through NAT masquerade to ETHER2 - ETHER1 comes online again, now it becomes mysterious:
- Connection through ETHER2 is switch back to ETHER1 but why?
- how is uninterrupted flow realized when switching interfaces as route changes?
- why is the connection now invalid?
- Connection is moved from ETHER2 to ETHER1 and stays connected, so there won't be any TCP three-way handshake sending out SYN (+ACK) from within the LAN
- The connection will not be made NEW, as this only happens to connection sending out SYN (+ACK)
- So it will not be MASQUERADED when flowing through ETHER1, as NAT only acts on NEW
Drop connection-state=invalid packets will work as the package cannot be identified within the CT of ETHER1, as the packets of the moved connection not belong to either a RELATED or ESTABLISHED connection (as there hasn't been any so far)?
.
- the route through ETHER1 closed --> all connections through ETHER1 are purged from connection-tracking (CT)
- see what is the shortest masquerade rule possible? - MikroTik
IP of masqueraded IP is always the IP of the interface, of course, it makes sense and you have to define the IP of an interface otherwise you don't have a route so the routing table is incomplete.
Where else is shall take it from when not defining it:
Assuming that be correct the shortest rule for Source NAT is:Code: Select all/ip address add address=xxx.xxx.xxx.xxx/yy interface=....
That would cause the src-IP in a packet flowing in through an interface (could be even a WAN-Interface) to be replaced by the interface's IP.Code: Select all/ip firewall nat add chain=srcnat
If the interface has more than one IP it is probably the first IP, isn't it?
My resources:
- Basic Concepts - RouterOS - MikroTik Documentation
- NAT - RouterOS - MikroTik Documentation
- Issues with internal traffic not getting NATed - MikroTik
- From masquerade to src-nat : mikrotik (reddit.com)
- iptables - Difference between SNAT and Masquerade - Unix & Linux Stack Exchange
- CONNTRACK
- MASQUERADE
- /ip/firewall/nat - srcnat masquerade - MikroTik
- Relevance of the out interface when masquerading - MikroTik
- Masquerade and SRC-NAT basics - MikroTik
- Decision for src-addr in Masquerade? - MikroTik
- Srce-nat 'masquerade' not catching all traffic? - MikroTik
- iptables (masquerade) appears to be leaking : linuxadmin (reddit.com)
- HELPERS