Community discussions

MikroTik App
 
PackElend
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 95
Joined: Tue Sep 29, 2020 6:05 pm

NAT: Masquerade can leak private IP, why&how?

Fri Jul 30, 2021 1:19 am

Hello MT-Forum,
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:
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:
  • 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.
To work around this situation blackhole route can be created as an alternative to the route that might disappear on disconnect.
...
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.
In addition, in Most underused and overused RouterOS features. My holy war against masquerade MUM, USA it is said the same in short:
  1. On disconnect, all related connection tracking entries are purged
  2. 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
  3. 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
but nowhere is said, why the established is:
  1. switch back to the primary link
  2. why the connection is not interrupted (remains ESTABLISHED during this process as the route changes
  3. why these mysterious NAT helpers don't make it appear as a NEW connection to connection-tracking


MY QUESTIONS, A&B:
  1. I'm struggling to describe the entire process, may someone can complete it, this is what I have:
    1. 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.
    2. 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
    3. ETHER1 comes online again, now it becomes mysterious:
      1. Connection through ETHER2 is switch back to ETHER1 but why?
      2. how is uninterrupted flow realized when switching interfaces as route changes?
      3. why is the connection now invalid?
        1. 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
        2. The connection will not be made NEW, as this only happens to connection sending out SYN (+ACK)
        3. 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)?
          .
  2. 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:

    /ip address  
    	add address=xxx.xxx.xxx.xxx/yy interface=.... 
    
    Assuming that be correct the shortest rule for Source NAT is:
    /ip firewall nat
    	add chain=srcnat
    
    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.
    If the interface has more than one IP it is probably the first IP, isn't it?


My resources:
  1. Basic Concepts - RouterOS - MikroTik Documentation
  2. NAT - RouterOS - MikroTik Documentation
  3. Issues with internal traffic not getting NATed - MikroTik
  4. From masquerade to src-nat : mikrotik (reddit.com)
  5. iptables - Difference between SNAT and Masquerade - Unix & Linux Stack Exchange
  6. CONNTRACK
    1. Connection Tracking (conntrack): Design and Implementation Inside Linux Kernel (arthurchiao.art)
    2. SIP connection tracking and NAT for Netfilter
    3. IPtables: Connection tracking (rigacci.org)
  7. MASQUERADE
    1. /ip/firewall/nat - srcnat masquerade - MikroTik
    2. Relevance of the out interface when masquerading - MikroTik
    3. Masquerade and SRC-NAT basics - MikroTik
    4. Decision for src-addr in Masquerade? - MikroTik
    5. Srce-nat 'masquerade' not catching all traffic? - MikroTik
    6. iptables (masquerade) appears to be leaking : linuxadmin (reddit.com)
  8. HELPERS
    1. Netfilter - Wikipedia
    2. Manual:IP/Services - MikroTik Wiki
    3. Netfilter Helpers (shorewall.org)
    4. How to disable H323 and RAS session helpers (fortinet.com)
Last edited by PackElend on Fri Jul 30, 2021 5:29 pm, edited 2 times in total.
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: NAT: Masquerade can leak private IP, how? & shortest masquerade rule possible?

Fri Jul 30, 2021 10:37 am

Not just masquerade, but even src nat and netmap leaks private IP. See the bottom of the article here
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 5896
Joined: Tue Feb 25, 2014 12:49 pm
Location: Capalbio, Tuscany, Italy

Re: NAT: Masquerade can leak private IP, how? & shortest masquerade rule possible?

Fri Jul 30, 2021 11:40 am

As I already wrote on another post:
[...]
"last ACK from Client" (TCP/ACK) or RST packet (TCP/RST)
[...] some router [RouterOS included] do not translate on NAT the source IP of the last packet used for close the connection,
[causing a Private IP leak]
and the packet, instead coming with Public IP, have one of the "bogon-used-on-lan" [Private IP]
Stopping that packet cause the service use more memory because from 30s to 30m the connection is still considerered open for lack of ACK (or RST)
[...]
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: NAT: Masquerade can leak private IP, how? & shortest masquerade rule possible?

Fri Jul 30, 2021 11:47 am

As I already wrote on another post:
[...]
"last ACK from Client" (TCP/ACK) or RST packet (TCP/RST)
[...] some router [RouterOS included] do not translate on NAT the source IP of the last packet used for close the connection,
[causing a Private IP leak]
and the packet, instead coming with Public IP, have one of the "bogon-used-on-lan" [Private IP]
Stopping that packet cause the service use more memory because from 30s to 30m the connection is still considerered open for lack of ACK (or RST)
[...]
That does not explain UDP or other transport protocols that escapes NAT. This is not exclusive to TCP and is replicable on Ubuntu 20.04 LTS or any Linux based distro.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 5896
Joined: Tue Feb 25, 2014 12:49 pm
Location: Capalbio, Tuscany, Italy

Re: NAT: Masquerade can leak private IP, how? & shortest masquerade rule possible?

Fri Jul 30, 2021 11:50 am

Oh, thanks, I do not have noticed UDP do that...
You already have some example of case when that happen?
I investigate further...
 
PackElend
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 95
Joined: Tue Sep 29, 2020 6:05 pm

Re: NAT: Masquerade can leak private IP, how? & shortest masquerade rule possible?

Fri Jul 30, 2021 12:34 pm

As I already wrote on another post:
where can I find this post?
Last edited by PackElend on Fri Jul 30, 2021 12:43 pm, edited 1 time in total.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 5896
Joined: Tue Feb 25, 2014 12:49 pm
Location: Capalbio, Tuscany, Italy

Re: NAT: Masquerade can leak private IP, how? & shortest masquerade rule possible?

Fri Jul 30, 2021 12:39 pm

Is this, but is not related with this problem.
viewtopic.php?f=13&t=177111&p=869308#p869297
 
pe1chl
Forum Guru
Forum Guru
Posts: 7795
Joined: Mon Jun 08, 2015 12:09 pm

Re: NAT: Masquerade can leak private IP, how? & shortest masquerade rule possible?

Fri Jul 30, 2021 3:08 pm

The problem with Linux NAT and therefore also with RouterOS NAT is that the NAT association is removed too soon at the end of a TCP connection.
If there is further traffic past the end of the connection (the end as far as the NAT handling is concerned) it either passes through untranslated or it creates a new and different NAT rule, depending on the settings and the firewall configuration.
The fix would be to keep NAT rules a while after the end of a connection (controlled by a timer). But even though settings exist that appear to be for such use, it apparently does not work that way.

Of course it is easy to block the bad packets in the firewall so they cannot escape, and also any decent internet provider would block them before sending them further down the road.
So it isn' really a big issue.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 5896
Joined: Tue Feb 25, 2014 12:49 pm
Location: Capalbio, Tuscany, Italy

Re: NAT: Masquerade can leak private IP, how? & shortest masquerade rule possible?

Fri Jul 30, 2021 3:48 pm

If it was up to me, I haved already revoked the license of all ISP that do not block IP spoofing.

It is extremely simple to block the sending of packets over the Internet
that have either a Private IP or a Public IP other than those that may exist in your internal network.
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: NAT: Masquerade can leak private IP, how? & shortest masquerade rule possible?

Fri Jul 30, 2021 4:58 pm

The majority of ISPs do not perform bogon filtering

Source: https://spoofer.caida.org/summary.php
 
PackElend
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 95
Joined: Tue Sep 29, 2020 6:05 pm

Re: NAT: Masquerade can leak private IP, how? & shortest masquerade rule possible?

Fri Jul 30, 2021 5:24 pm

Is this, but is not related with this problem.
viewtopic.php?f=13&t=177111&p=869308#p869297
thx but I would not say so as
...or have invalid characteristics for new connection (e.g. fail to establish the 3-way handshake for new TCP connection)...
brings some insights into how the switched back connection could become invalid.

I'm still having problems follow your post may it is summarized too extremely :), would you mind rephrasing it?


The only thing still being 100% unclear, why the connection is switched back from backup to primary and the connection is kept alive.


I split question B to another topic, as it becomes unrelated to his one: what is the shortest masquerade rule possible? - MikroTik
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 5896
Joined: Tue Feb 25, 2014 12:49 pm
Location: Capalbio, Tuscany, Italy

Re: NAT: Masquerade can leak private IP, how? & shortest masquerade rule possible?

Fri Jul 30, 2021 5:42 pm

The only thing still being 100% unclear, why the connection is switched back from backup to primary and the connection is kept alive.
If for some reason the main gateway go down and some connection-tracking connections are still presents,
untill main gateway is down are all invalid and useless, and can cause problem for example with SIP/VoIP on the backup/secondary connection.

When the main gateway come back online, the connection-tracking have mixed invalid connections because some are for backup/secondary and
some are present before previous unreachability from main gateway.

The better way is (if used) delete all tracked connection when gateway change. On this way everytime are valid.

I hope you understand now.
 
PackElend
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 95
Joined: Tue Sep 29, 2020 6:05 pm

Re: NAT: Masquerade can leak private IP, why&how?

Fri Jul 30, 2021 6:00 pm

In NAT - RouterOS - MikroTik Documentation it is stated:
...on disconnect, all related connection tracking entries are purged...
so I expect I don't have to delete anything as ROS does it anyway when a link goes down.
Connections are going to reconnected through the backup GW afterwards.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 5896
Joined: Tue Feb 25, 2014 12:49 pm
Location: Capalbio, Tuscany, Italy

Re: NAT: Masquerade can leak private IP, why&how?

Fri Jul 30, 2021 6:08 pm

I do not know why you insist, insisting can't change things.
About that is my last reply.
Connections are going to reconnected through the backup GW afterwards.
NO, the previous connections are invalid and are not used again,
only new connections are estabilished, and are not "reused" or re- anything for backup gateway.
 
PackElend
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 95
Joined: Tue Sep 29, 2020 6:05 pm

Re: NAT: Masquerade can leak private IP, why&how?

Fri Jul 30, 2021 10:20 pm

Connections are going to reconnected through the backup GW afterwards.
NO, the previous connections are invalid and are not used again,
only new connections are established, and are not "reused" or re- anything for backup gateway.
my bad, we are meaning the same but my wording is misleading.

Let me try again.
  1. traffic goes to the primary link --> packets are conntracked
  2. primary link goes down --> connection is interrupted/killed --> conntrack-table is purged/cleaned/emptied (but connections remains open at target, acc. #1 and #2)
  3. clients reinitiated connections --> ROS takes next available interface to www, the one with the lowest distance --> traffic goes through backup link
  4. killed traffic is added as NEW to the conntrack-table of the backup link and will be become ESTABLISHED or RELATED
  5. primary link comes back
    ---> ???, now I guess:
  1. due to the return of the primary link ROS triggers a recalculation of routes --> ROS notices that there is a shorter route than the currently active route via the backup link?
  2. ROS says let's go the shorter way and sends new outgoing packets of ESTABLISHED connection via the primary link (only des-MAC at layer 2 is changed)?
  3. although being routed differently connection is still being accepted at the target as (the route is not recorded and) it still has the same "ID" it may take only a different door to get in?
  4. there is no record of TCP-Handshake at conntrack-table of the primary-link, so the connection becomes invalid?
 
sindy
Forum Guru
Forum Guru
Posts: 7910
Joined: Mon Dec 04, 2017 9:19 pm

Re: NAT: Masquerade can leak private IP, why&how?

Sat Jul 31, 2021 9:21 am

There are two separate phenomena that cause the leakage.

A src-nated connection is only removed from the connection tracking list when the router loses the address used as that connection's reply-dst-address and the src-nat handling has been triggered by an action=masquerade rule. Connections whose src-nat handling has been triggered by an action=src-nat are not removed even if the reply-dst-address is lost.

As you have found out yourself, when the primary WAN link re-establishes, the routing changes, but as the secondary WAN link does not go down at the same time, the connections that have established via the secondary WAN are not removed from the connection tracking table, so their NAT handling (which may also be none depending on the overall setup) is applied also on packets that are now routed via the primary WAN.

One possible way out is to use connection marks and assign them depending on the WAN that has actually been used for that connection, i.e. the WAN through which the first response packet has arrived, rather than depending on the WAN we want the initial request to leave through. If the initial request uses a routing table that prefers the primary WAN, but the primary WAN is not available and thus the request is sent via the secondary one, the first response will arrive via the secondary WAN. You can make the connection remember this by assigning a connection-mark value in prerouting depending on in-interface for WAN->LAN traffic, and then translating that connection-mark value into a routing-mark one for LAN->WAN traffic, whilst that routing-mark will indicate a routing table which does not prefer one of the WAN routes but uses it exclusively (so if it that route is down, the packet is dropped).

This way, connections that have been established via the secondary WAN will keep using it even if the primary one recovers, preventing them from failing and leaking the "wrong" IPs (i.e. the private ones or the one assigned to the secondary WAN) via the primary WAN.

All the above is completely unrelated to the other issue discussed in this topic, i.e. that TCP connections are removed from the connection tracking tables too early, so subsequent packets of the same TCP session are not identified as part of that (already non-existent) connection and thus are forwarded without source address modification. This issue is only related to TCP (and maybe SCTP), definitely not to stateless L4 protocols.

It should be possible to make the filter drop these "post-mortem" TCP packets by allowing only connection-state=established,related or tcp-flags=SYN,!ACK packets to pass through also in the LAN->WAN direction. In the default firewall rules, LAN->WAN traffic is not filtered at all past the rules matching at connection-state, and the action=drop connection-state=invalid rule seems to fail to drop these "post-mortem" TCP packets - possibly because loose-tcp-tracking is set to yes by default?

I wish I knew this 10 years ago when running OpenWRT with a PPP modem that froze each time a packet with the source IP unchanged has leaked and the ISP has disconnected the ppp session due to that, and needed a power reboot which my Asus WL-500g was unable to provide.
Don't write novels, post /export hide-sensitive file=x. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
Guscht
Frequent Visitor
Frequent Visitor
Posts: 77
Joined: Thu Jul 01, 2010 5:32 pm

Re: NAT: Masquerade can leak private IP, why&how?

Sat Jul 31, 2021 12:26 pm

Hi,

just a few thoughts....
What would be the effect of simply setting multiple masquerading rules, like:

Out-I/F ETH1 (Main-WAN); Action: Masq
Out-I/F ETH2 (Backup-WAN); Action: Masq

In this case the masquerading is interface specific and should not stop on ETH2 if ETH1 comes back...?

And is this real problem if private-IPs are leaked - or a theoretical thought?

The ISPs do not route private IPs, so maybe the packet reaces the destination, but the way back is impossible.
In this case the initial connection must be re-established with the correct SNA/Masq public IP to get an answer.
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: NAT: Masquerade can leak private IP, why&how?

Sat Jul 31, 2021 12:30 pm

All the above is completely unrelated to the other issue discussed in this topic, i.e. that TCP connections are removed from the connection tracking tables too early, so subsequent packets of the same TCP session are not identified as part of that (already non-existent) connection and thus are forwarded without source address modification. This issue is only related to TCP (and maybe SCTP), definitely not to stateless L4 protocols.
Personally seen UDP traffic leaking from NAT as well in both:
  • A home setup where Router>WireGuard Server (Linux NAT device) leaks src IP of the private subnet to the router
  • ASN level topology where CGNAT devices leaks non src NATted packets to the edge router which exits to the upstream peers unless of course bogon filtered
 
sindy
Forum Guru
Forum Guru
Posts: 7910
Joined: Mon Dec 04, 2017 9:19 pm

Re: NAT: Masquerade can leak private IP, why&how?

Sat Jul 31, 2021 1:07 pm

Personally seen UDP traffic leaking from NAT as well in both:
I didn't write that an UDP packet can never leak with a source IP unchanged - I just wrote that it cannot happen where the removal of the NATed connection from the list of tracked ones is caused by that connection being terminated at protocol level. And termination at protocol level is only possible for stateful protocols understood by the connection tracking module of the firewall.

But maybe I was too narrow-minded - possibly there is a protocol that uses UDP as transport, is stateful internally (L5 to L7), and the firewall understands its statefulness at these layers. It comes to my mind that if a SIP call is terminated by a response to a BYE and the SIP ALG functionality is enabled, if the endpoint keeps sending RTP even after sending the BYE or the response to the BYE, that RTP may stop getting src-nated. But I have never tried this - "normal" endpoints first disable the RTP and then respond to the BYE.

Nevertheless, I'd attribute both of your examples to the other type of issue, where the connection gets established via one route, which need not necessarily be a WAN one in the narrow sense, and then it continues for a while after the routing changes. E.g. with the VPN, if the VPN tunnel goes down for some reasons, the route via that tunnel becomes unavailable, so packets towards VPN destinations, which belong to connections initiated while the VPN was up, start being sent via the "real" WAN instead. But since the initial packet of such a connection didn't match a src-nat rule, also the packets leaving via the "real WAN" keep their original source address. The srcnat and dstnat rule chains only handle the initial packet of each connection; the rest of the packets of the same connection inherits the same handling. This is the only possible way - think about the need to "un-nat" the responses.

The difference is that with dual WAN arrangement, people usually use multiple WANs because they expect them fail now and then, so they use backup routes intentionally; with the VPN destinations, the "failover" from VPN to WAN is not a planned thing so it doesn't come to one's mind to think about it.
Don't write novels, post /export hide-sensitive file=x. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
Guscht
Frequent Visitor
Frequent Visitor
Posts: 77
Joined: Thu Jul 01, 2010 5:32 pm

Re: NAT: Masquerade can leak private IP, why&how?

Sat Jul 31, 2021 1:29 pm

One thing about the Mikrotik Wiki:

/ip firewall nat add chain=srcnat src-address=10.0.0.0/24 action=masquarade out-interface=WAN

Every time when interface disconnects and/or its IP address changes, the router will clear all masqueraded connection tracking entries related to the interface, this way improving system recovery time after public IP change. If srcnat is used instead of masquerade, connection tracking entries remain and connections can simply resume after a link failure.

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:

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 packet will 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.

They refer to "action=masquarade out-interface=WAN", WAN is a single Interface. The following cant be related to this example:
"when the connection gets routed over different links". But how can this SNAT/Masq-Rule match "different links"? This rules matches only Interface "WAN".

It is unclear if they mean multiple SNAT/Masq-rules or an Interface List, with all WAN-Interfaces grouped (with a single SNAT/Masq-rule)?

How is the outcome:
  • 1 SNAT/Masq-Rule with WAN-Interface-List (as Out Interface List)
  • multiple SNAT/Masq-Rules with dedicated WAN-Interfaces (Out Interface)
 
DarkNate
Member
Member
Posts: 387
Joined: Fri Jun 26, 2020 4:37 pm

Re: NAT: Masquerade can leak private IP, why&how?

Sat Jul 31, 2021 1:37 pm

WAN is a single Interface.
WAN is an interface list and can contain n number of underlying interfaces. It's not a single interface.
 
sindy
Forum Guru
Forum Guru
Posts: 7910
Joined: Mon Dec 04, 2017 9:19 pm

Re: NAT: Masquerade can leak private IP, why&how?

Sat Jul 31, 2021 2:56 pm

How is the outcome:
  • 1 SNAT/Masq-Rule with WAN-Interface-List (as Out Interface List)
  • multiple SNAT/Masq-Rules with dedicated WAN-Interfaces (Out Interface)
There's no difference in the outcome.

Expanding into more detail:

/interface list add name=WAN
/interface list member
add interface=wan1 list=WAN
add interface=wan2 list=WAN
/ip firewall nat
add action=masquerade out-interface-list=WAN


will treat the traffic exactly the same as

/ip firewall nat
add action=masquerade out-interface=wan1
add action=masquerade out-interface=wan2


Each tracked connection is handled individually and information about in-interface (or -list) and out-interface (or -list) is not stored in that connection's data record. What is stored, though, is whether the connection is bound to a particular own address of the router and has to be removed if that address is lost, and this behaviour is only used if the NAT handling was ordered by an action=masquerade rule. So the connections are dropped not only when the interface holding that address goes down, but also when a lease of a dynamic address expires and a different address is assigned. The latter is actually the very purpose of masquerade, the former (removal of connections when an interface goes down) is a side effect.
Don't write novels, post /export hide-sensitive file=x. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
PackElend
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 95
Joined: Tue Sep 29, 2020 6:05 pm

Re: NAT: Masquerade can leak private IP, why&how?

Sun Aug 01, 2021 8:56 pm

I looks like that I opened a can of worms considering all the answers, very recent references/links, and the technical details, what is really good.
All the above is completely unrelated to the other issue discussed in this topic, i.e. that TCP connections are removed from the connection tracking tables too early, so subsequent packets of the same TCP session are not identified as part of that (already non-existent) connection and thus are forwarded without source address modification. This issue is only related to TCP (and maybe SCTP), definitely not to stateless L4 protocols.
I don't mind going beyond the scope of my question. Acutally I would quite happy to do so :).
I could easily rename it to "NAT and private IP leaking/escaping" to summerize what is said in here to avoid peopel like me or
just a few thoughts....
being lost in thoughts and assumptions :).


I could start with masqueraded assuming that what I said is correction based on:
As you have found out yourself, when the primary WAN link re-establishes, the routing changes, but as the secondary WAN link does not go down at the same time, the connections that have established via the secondary WAN are not removed from the connection tracking table, so their NAT handling (which may also be none depending on the overall setup) is applied also on packets that are now routed via the primary WAN.
so there is kind of auto-optimization as recalculation triggers port switching to the shortest route to the destination.
This could also give answer to
1b) If I'm not sure if coming back faulty gateway the disrupted connections works again...
said in Advanced Routing Failover without Scripting - MikroTik
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 5896
Joined: Tue Feb 25, 2014 12:49 pm
Location: Capalbio, Tuscany, Italy

Re: NAT: Masquerade can leak private IP, why&how?

Mon Aug 02, 2021 11:14 am

WAN is a single Interface.
WAN is an interface list and can contain n number of underlying interfaces. It's not a single interface.
When the wiki was written, at the time do not exist WAN/LAN groups, the default-config inside RouterOS chage over time.

this on the wiki
/ip firewall nat add chain=srcnat src-address=10.0.0.0/24 action=masquarade out-interface=WAN
are intended a single WAN interface called WAN, indeed the rule are out-interface=WAN, not out-interface-list=something
 
PackElend
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 95
Joined: Tue Sep 29, 2020 6:05 pm

Re: NAT: Masquerade can leak private IP, why&how?

Wed Aug 04, 2021 10:21 am

Good morning,
do you agree with my latest theory of primary link restoration?
I would update the OP accordingly.

thank you
Stefan
 
PackElend
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 95
Joined: Tue Sep 29, 2020 6:05 pm

Re: NAT: Masquerade can leak private IP, why&how?

Wed Aug 11, 2021 10:38 pm

MikroTik support replied
It will switch automatically if the default route with a shorter distance will come up.
but have not got an in-depth answer yet.

Who is online

Users browsing this forum: Ahrefs [Bot], Baidu [Spider], Bing [Bot] and 56 guests