Mit ROS v7.10 wurde „EIN“ (Endpoint Independent NAT) implementiert.

*) firewall – added „endpoint-independent-nat“ support;

 

Eine wirkliche Erklärung mit Beispielen bleibt Mikrotik schuldig:
https://help.mikrotik.com/docs/display/ROS/NAT#NAT-Endpoint-IndependentNAT

 

Wie funktioniert EIN?

Dargelegt ist das Verhalten in RFC 5128, Abschnitt 2.2.3 und 2.2.5:
https://www.ietf.org/rfc/rfc5128.txt

 

Mikrotiks Definition:

Endpoint-independent NAT creates mapping in the source NAT and uses the same mapping for all subsequent packets with the same source IP and port.

 

NAT wird generell in ein Mapping und ein Filtering unterteilt.

Ausgehende (SNAT behandelte) Pakete bekommen ein Mapping im Connection-Tracking, welches für alle folgenden Pakete gleich bleibt, wenn die Quell-IP und der Quell-Port gleich bleiben. Deswegen Endpoint (Ziel-IP) Idependent (unabhängig). Von der normalen (mikrotik’schen) SNAT-Logik unterscheidet sich das nicht sehr, da ROS dieses Verhalten immer schon hatte. Der Quell-Port wurde i. d. R. beibehalten, außer es wurde von einem anderen Host der gleiche Quell-Port mit der gleichen Ziel-IP:Port-Kombination verwendet. In dem Fall wurde ein zufällig gewählter Highport (als SNAT-behandelter Quellport) gewählt.

Diese Funktionalität ist also nicht wirklich spannend. Interessant wird es, wenn EIN auf der DNAT-Chain angewendet wird. Dadurch ergibt sich eine Art „dynamisches DNAT“.

Mikrotik schreibt dazu:

This mapping allows running source-independent filtering, which allows forwarding packets from any source from WAN to mapped internal IP and port.

 

Zu beachten ist, dass sich dann JEDE beliebige öffentliche IP auf das zuvor (SNAT) stattgefundene Mapping verbinden darf. Anders gesagt, der Host (im LAN) ist dann für das ganze Internet unter dem (initial ausgehendem) Quellport erreichbar.

 

Mikrotik beschreibt zwei NAT-Regeln:

/ip firewall nat
add action=endpoint-independent-nat chain=srcnat out-interface=WAN protocol=udp

/ip firewall nat
add action=endpoint-independent-nat chain=dstnat in-interface=WAN protocol=udp

 

Lab

Die beiden Regeln – SNAT und DNAT-Chain:

 

 

Wenn eine Firewall konfiguriert ist, muss eine entsprechende (erlaubende) Connection-NAT-State-Regel angelegt sein:

 

Wird nun ausgehend eine BELIEBIGE öffentliche IP kontaktiert (hier 8.8.8.8), wird das EIN-Mapping erstellt:

Dieser Host nun für alle Hosts im Internet auf dem Port 64971 erreichbar!

Die ausgehenden Pakete:

 

Testet man das nun von einem beliebigen Host – NICHT 8.8.8.8:

Sind eingehend Pakete sichtbar, für die KEINE normale DNAT-Regel angelegt wurde!
Hier wirkt das „Endpoint Independent Filtering“:

 

Im ConnTracking sieht das Ganze so aus:

 

Es kann so NUR der initiale Quellport dynamisch-öffentlich erreichbar gemacht werden!
Die Option „Randomise Port“ hat auf der SNAT-Chain ebenfalls einen Effekt.

Wenn im ConnTracking das ausgehende Mapping (Cs) abläuft (UDP hat einen Standard-Timeout von 10 Sekunden), können keine eingehenden Pakete (Cd) empfangen werden. Wenn ein eingehendes Filtering (Cd) aktiv ist, das ausgehende Mapping (Cs) aber abläuft, können noch so lange Pakete (eingehend) empfangen werden, wie das Cd-Mapping aktiv ist.

 

Ausblick

Ab ROS v7.12 wird es eigene Matcher für EIN-getrackte Flows geben:

*) firewall – added „ein-snat“ and „ein-dnat“ connection NAT state matchers for filter and mangle rules;

 

Das lässt eine granularere Steuerung zu.

 

Referenzen

• https://www.ietf.org/rfc/rfc5128.txt
• https://help.mikrotik.com/docs/display/ROS/NAT#NAT-Endpoint-IndependentNAT