I would like to report a strange behavior I am experiencing on two different MikroTik routers, running RouterOS v7.18.1 and v7.20.4.
Problem description
Under certain conditions, some traffic flows bypass the NAT rules that should be applied.
As a result, the traffic leaves the router without being NATed, even though the corresponding src-nat / masquerade rule exists and is correctly configured.
This does not happen consistently:
Most traffic is NATed correctly
Only some specific flows/sessions are affected
The issue appears intermittently
Expected behavior
All traffic matching the NAT rule should always be NATed before leaving the router.
Actual behavior
Some flows pass through the router without NAT being applied, causing:
Traffic to egress with private IP addresses
Connectivity issues on the upstream network
Environment
RouterOS versions affected:
v7.18.1
v7.20.4
The issue occurs on two different MikroTik devices
NAT rules are simple and standard (no fasttrack involved)
Firewall and NAT order has been verified
No policy routing is used for the affected traffic
I should have provided more details from the beginning. I was initially wondering whether other users had experienced the same behavior or a similar issue.
I have a router that terminates all PPPoE connections and works as a BRAS. Behind this router, I have two MikroTik routers. Using ACLs, I forward traffic from specific private IP ranges to these MikroTik routers so they can perform NAT.
After that, the MikroTik routers send the traffic back to the main router with NAT already applied (using public IPs instead of private IPs). However, the problem is that some traffic returns without NAT being applied.
Internet
|
\[ Upstream / Transit \]
|
(Public IP / BGP / GW)
|
+-------------------+
| ROUTER BRAS |
| (PPPoE Server) |
| Termina sesiones |
+-------------------+
| |
| |
PPPoE clients (private IPs assigned on PPPoE)
|
|
------------------------------------------------
| |
+-------------------+ +-------------------+
| MikroTik #1 | | MikroTik #2 |
| RouterOS v7.18.1 | | RouterOS v7.20.4 |
| "NAT Gateway" | | "NAT Gateway" |
+-------------------+ +-------------------+
| |
| Receives private IP traffic from Main Router |
| (source = customer private IP) |
| |
+--------------------+ +---------------------+
\\ /
\\ /
NAT applied here
(src-nat / masquerade)
|
|
Returns NATed traffic
back to Main Router BRAS
|
v
+-------------------+
| Main router BRAS |
| sends to Internet |
+-------------------+
Here it is one of the mikrotik config:
/interface bonding
add mode=802.3ad name=bondingPBR slaves=sfp-sfpplus1,sfp-sfpplus2 transmit-hash-policy=layer-3-and-4
/interface vlan
add comment="LAN - Clientes" interface=bondingPBR name=vlan1204 vlan-id=1204
add comment="WAN - retorno" interface=bondingPBR name=vlan1304 vlan-id=1304
/ip firewall connection tracking
set tcp-established-timeout=7h
/ip neighbor discovery-settings
set discover-interface-list=none lldp-dcbx=no protocol=lldp
/ip settings
set tcp-syncookies=yes
add address=100.70.30.2/30 interface=vlan1204 network=100.70.30.0
add address=100.70.31.2/30 interface=vlan1304 network=100.70.31.0
Isn't it possible that you see remainings packets of disconnected sessions?
There is 7h connection timeout set, so if client dissconets abnormally then connection still lives for a quite a long time however it has no matching end to do the proper nat.
Indeed there are known cases where some non-NATed packets may bleed out due to how connection tracking works. And the solution is to create a (raw?) firewall rule which drops such packets on WAN interface. If you're considering implementing such filters on ISP routers, then you probably should consider a blackhole route for such packets.
That is a possibility, however, even though the screenshot only shows a couple of connections, there are actually multiple clients experiencing connections that go outside of NAT.
These are active connections, not leftover packets from disconnected sessions. From what I was able to verify, the clients do not experience disconnections, and the sessions remain established while the traffic is being forwarded without NAT.
What I had to do as a mitigation was to create an ACL on the main router to drop traffic returning from the MikroTik with private source IPs, meaning traffic that was not NATed. This helps mitigate the impact, but the issue itself still remains and seems to originate from the MikroTik behavior.
You mentioned that there are other known cases. Are you aware of other users reporting NAT-related issues in recent RouterOS v7 versions as well?
