Jun 11, 2015, updated at Jun 16, 2015 (UTC)

9042

Routing ohne doppeltes NAT

Hallo,

bin nun schon ne Weile am rumprobieren. (hab hier auch zahlreiche hervorragende Tutorials durchgespielt, bisher leider ohne Erfolg)

Ich möchte von den verschiedenen Netzen ohne die NAT Regel in's Internet kommen....

eth 1 / gateway dhcp client 192.168.1.10
eth 2 -> 172.1.1.0/24
eth 3 -> 172.1.2.0/24

meine route :

 
[admin@MikroTik] > ip route print
Flags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADS  0.0.0.0/0                          192.168.1.1               0
 1 ADC  172.1.1.0/24       172.1.1.1       ether2                    0
 2   S  172.1.1.0/24                       ether1                    1
 3 ADC  172.1.2.0/24       172.1.2.1       ether3                    0
 4   S  172.1.2.0/24                       ether1                    1
 5 ADC  192.168.1.0/24     192.168.1.103   ether1                    0

ich seh den Wald nicht mehr ....

edit : Bild eingefügt

Please also mark the comments that contributed to the solution of the article

Content-Key: 274320

Url: https://administrator.de/contentid/274320

Printed on: April 18, 2024 at 11:04 o'clock

47 Comments

Latest comment

Moinsens,
erst mal du wirfst hier einfach so was in die Runde ohne mal konkret deinen Netzwerkaufbau zu erläutern.
Wenn du eine Routerkaskade betreibst (also noch ein Router vor deinem Mikrotik sitzt) wovon du nichts erwähnt hast, gehören auf diesen vorgeschalteten Router (192.168.1.1) statische Routen für die Netze die du auf dem Mikrotik betreibst, welche auf den Mikrotik als GW zeigen. In diesem Fall kann das NAT auf dem Mikrotik entfallen.
Also auf den Router mit der 192.168.1.1 folgende statische Routen anlegen dann lüppt dat:

NETZ 172.1.1.0/24 / Gateway 192.168.1.103
NETZ 172.1.2.0/24 / Gateway 192.168.1.103

Und die statischen Routen die du auf dem MK angelegt hast gehören sofort wieder in die Tonne, die sind absoluter Schwachsinn, und du hast das Routing-Prinzip leider noch nicht verstanden !! Wieso sollte der MK auf sich selbst routen ?? der kennt die Netze ja schon ;-P

Gruß jodel32

ich seh den Wald nicht mehr ....

logisch... Wald gehört mir, Zutritt kostet Eintritt

Zitat von @fredfred:

ich seh den Wald nicht mehr ....

Dann fäll mal ein paar Bäume.

Moin,

Wie jodel schon sagte: mal mal Deine Infrastruktur mit Netzen auf udn dann sieht man auch, welche Route wo eingetragen werden muß.

Sofern Du nur einen Router hast, mußt Du auf dem normalerweise gar keine Route einrtagen, weil der ja alle seine Anschlüsse kennt.

lks

Wenn du eine Routerkaskade betreibst (also noch ein Router vor deinem Mikrotik sitzt) wovon du nichts erwähnt hast,
gehören auf diesen vorgeschalteten Router (192.168.1.1) statische Routen für die Netze die du auf dem Mikrotik
betreibst, welche auf den Mikrotik als GW zeigen. In diesem Fall kann das NAT auf dem Mikrotik entfallen.

Manomann.....
ist eigentlich logisch ...

Ja, ich hab noch eine Firewall (pfsense)

Aber wie finden Die Netze von ETH 2, 3 und 4 zum Gateway ?

> ich seh den Wald nicht mehr ....
logisch... Wald gehört mir, Zutritt kostet Eintritt

wenn Du in der nähe bist gibt's en Kasten Bier !

hab oben noch ein Bildchen reingehängt ....

Danke für den wink

Gruss vom Förster

Zitat von @fredfred:

Ja, ich hab noch eine Firewall (ipfire)

Gib dem Mikrotik eine statische Adresse zur IP-Fire hin und trage auf der IP-Fire die Netze ein, daß die üer den Mikrotik erreichbar sind. Der Microtik braucht eigentlich nur eine default-Route zur IP-Fire. Dann wird alles gut.

lks

PS. ISt das Problem schon gelöst oder hast Du nur aus Versehen auf gelöst geklickt?

PS. ISt das Problem schon gelöst oder hast Du nur aus Versehen auf gelöst geklickt?

nö, werde mich erst morgen früh wieder in den Wald begeben...
(wie krieg ich das "gelöst" wieder wech?

Zitat von @fredfred:

> PS. ISt das Problem schon gelöst oder hast Du nur aus Versehen auf gelöst geklickt?

nö, werde mich erst morgen früh wieder in den Wald begeben...
(wie krieg ich das "gelöst" wieder wech?

Einfach "Beitrag barbeiten" und dann den Haken bei gelöst wegnehmen.

lks

Wichtig ist das du die Default Konfig auf dem Mikrotik löschst !
Eigentlich erklärt das Tutorial hier genau wie es geht:

Routing von 2 und mehr IP Netzen mit Windows, Linux und Router

Wenn man sich daran hält klappt alles wie es soll ohne NAT !
Wo ist genau dein Problem ?

hab im MT alles gelöscht ..

Adressen nochmals wie oben eingetragen.

die routen im pfsense hinzugefügt.

aber es will nicht klappen .

Öhm ist jetzt der Mikrotik derjenige Router welcher die DSL-Verbindung herstellt oder die PFSense ??
Und dann schreibst du :

Ja, ich hab noch eine Firewall (ipfire)

Und jetzt ne PFSense ??

Also mach endlich mal klar wie dein Netzwerkaufbau genau aussieht ! Danke.

Zitat von @fredfred:

die routen im pfsense hinzugefügt.

Meinst Du die IP-Fire oder wo ist die pfsense hegekommen?

lks

Dein Mikrotik hat laut deiner eingefügten Grafik die 192.168.1.10 nicht die .103 ... also sind die statischen Routen alle falsch.

Dir sollte auch klar sein das die Firewalls der Clients dir einen Streich spielen können, denn bei Windows werden Pings aus fremden Subnetzen per Default von der Firewall geblockt !

Also auf diesen ICMP etc freischalten und dann mit tracert checken wie das Routing läuft, ist doch nicht so schwer wenn man sich denn mal die Routing-Grundlagen reinziehen würde, aber nee bloß keine Grundlagen lesen, lieber Trial & Error ....verkehrte Welt.

Zitat von @114757:

Dein Mikrotik hat laut deiner eingefügten Grafik die 192.168.1.10 nicht die .103 ... also sind die statischen Routen alle
falsch.

Hab das Bild angepasst.

Dir sollte auch klar sein das die Firewalls der Clients dir einen Streich spielen können, denn bei Windows werden Pings aus
fremden Subnetzen per Default von der Firewall geblockt !

es ist ein Appel

Ping von diesem geht bis WAN des MT (192.168.1.103)

Firewall der PFSense sollte natürlich Traffic zwischen diesen Netzen erlauben ! Diese also erst mal auf Durchzug (any-to-any Regel) schalten.

Zitat von @114757:

Firewall der PFSense sollte natürlich Traffic zwischen diesen Netzen erlauben ! Diese also erst mal auf Durchzug (any-to-any
Regel) schalten.

Wobei mri aber imemr noch nicht klar ist, wo die pfsense stecken soll? Auf dem Schaubild ist imemr noch nur ein Microtik und eine IPFire zu sehen.

lks

aber es will nicht klappen .

Nur mal dumm nachgefragt: Die Default Route im Mikrotik auf die IP LAN Adresse der pfSense hast du gesetzt ?!
(Sorry, ja sehe ich gerade...)
Zweite Frage:
Hast du irgendwelche FW Regeln am LAN Interface aktiv ?
Wenn ja musst du logischerweise dafür sorgen das die 172er Netze des MT dort passieren dürfen.
Entfällt natürlich wenn du die Default "Scheunentor Regel" mit allow any any am LAN Port hast, klar. (Siehe auch Tip vom Kollegen LKS und jodel )

Was sagt ein Traceroute von einem der MT Subnetze auf den pfSense LAN Port ?
Was sagt ein Ping von einem der MT Subnetze auf den pfSense LAN Port ?

Wobei mri aber imemr noch nicht klar ist, wo die pfsense stecken soll? Auf dem Schaubild ist imemr noch nur ein Microtik und eine
IPFire zu sehen.

lks

hab das bild nochmals angepasst .... es gibt nur ein pfsense und ein MT

Dann ist da aber irgendwie ein Fehler !
Die Zeichnung hat die IP .1.10 am MT aber in der Konfig ist das .1.103 ! Was stimmt denn nun ??

Tests die du machen solltest:

Ping vom pfSense GUI (Diagnostics) mit der LAN Absender IP (Source) auf die MT Adresse an eth1 wo die verbunden sind 192.168.1.103 (oder .1.10 ?!)
Ping vom pfSense GUI (Diagnostics) mit der LAN Absender IP (Source) auf die MT Subnetz Adressen 172.x.y
Ping vom MT (CLI oder Winbox oder WebGUI) auf die pfSense IP 192.168.1.1
Das gane auch nochmal mit Traceroute.
Checke mal mit ipconfig oder ifconfig ob die Endgeräte in den MT Subnetzen eine richtige IP und Gateway (MT IP) bekommen !
Wichtig ist in jedem Falle ob es eine FW Regel am LAN Port der pfSense gibt !

Zitat von @aqui:

Dann ist da aber irgendwie ein Fehler !
Die Zeichnung hat die IP .1.10 am MT aber in der Konfig ist das .1.103 ! Was stimmt denn nun ??

bild ist angepasst (192.168.1.10)

Tests die du machen solltest:

Ping vom pfSense GUI (Diagnostics) mit der LAN Absender IP (Source) auf die MT Adresse an eth1 wo die verbunden sind

192.168.1.103 (oder .1.10 ?!)

geht

* Ping vom pfSense GUI (Diagnostics) mit der LAN Absender IP (Source) auf die MT Subnetz Adressen 172.x.y

geht

* Ping vom MT (CLI oder Winbox oder WebGUI) auf die pfSense IP 192.168.1.1

geht

* Das ganze auch nochmal mit Traceroute.

geht auch

* Checke mal mit ipconfig oder ifconfig ob die Endgeräte in den MT Subnetzen eine richtige IP und Gateway (MT IP)
bekommen !

das passt
z.b eth 2 / ip 172.1.1.200 / Gateway 172.1.1.1 / DNS 172.1.1.1

ein Ping vom client 172.1.1.200 auf die ETH1 von MT geht (192.168.1.103) auf die pfsense 192.168.1.1 jedoch nicht ...

* Wichtig ist in jedem Falle ob es eine FW Regel am LAN Port der pfSense gibt !

Zitat von @fredfred:
> * Wichtig ist in jedem Falle ob es eine FW Regel am LAN Port der pfSense gibt !

Wie schon vermutet, da fehlen die Regeln für die Mikrotik Netze auf dem LAN Interface
LAN net ist ja vermutlich nur das 192.168.1.x Subnetz

auf die pfsense 192.168.1.1 jedoch nicht ...

Kollege Jodel hat Recht !!!
Du hast hier eine Firewall und die lässt in den von dir geposteten Regeln eben nur Pakete aus dem LAN Netzwerk also der 192.168.1.0 /24 zu !!
Ist dir ja schon mehrfach gesagt worden oben

Erweiter also die Regeln am pfSense LAN Port:

Pass, Protocol: IPv4, Source: 172.16.0.0, Maske: 255.255.252.0 (22 Bit), Port: any --> Destination: any, Port: any

Damit lässt dann die Firewall nun auch deine MT IP Netze 172.16.0.0, .1.0, .2.0 und .3.0 mit einer 24 Bit Maske am LAN Port der pfSense passieren !
Wenn du die Subnetzmakse der Regel um 1 erniedrigst (21 Bit, 255.248.0) dann können alle IP Netze bis .7.0 passieren, noch ein Bit mehr bis .15.0 usw. usw.

Eigentlich wie immer ganz einfach und wie bei einer Firewall üblich !

Habe die sense auf "Factory defaults" gesetzt...

WAN Zugang eingerichtet, MT kommt ins Internet.
Bei den Clients klappt es immer noch nicht.
Ping von diesen bis auf PFsense LAN 192.168.1.1 geht nun.
Auch ein Ping von Clients auf den WAN der Pfsense geht durch

Der zusätzliche Gateway

Die Route

Die FW Regel

WAS ist auf den Clients als Default Gateway und DNS gesetzt ??
Bitte mal ein ipconfig -all hier posten ?

Kannst du einen nackte IP im Internet von den Clients aus anpingen z.B. 8.8.8.8 ?
Kannst du die 8.8.8.8 pingen direkt von der pfSense (Diagnostics)
Kannst du die 8.8.8.8 pingen direkt vom MT ?
Kannst du die 8.8.8.8 vom MT tracerouten (Traceroute) ?

Zitat von @aqui:

WAS ist auf den Clients als Default Gateway und DNS gesetzt ??
Bitte mal ein ipconfig -all hier posten ?

schnipp -----
IPv4-Adresse . . . . . . . . . . : 172.1.3.253(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Samstag, 13. Juni 2015 14:04:01
Lease läuft ab. . . . . . . . . . : Dienstag, 16. Juni 2015 14:04:02
Standardgateway . . . . . . . . . : 172.1.3.1
DHCP-Server . . . . . . . . . . . : 172.1.3.1
DNS-Server . . . . . . . . . . . : 172.1.3.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
---schnapp

Kannst du einen nackte IP im Internet von den Clients aus anpingen z.B. 8.8.8.8 ?

nein

* Kannst du die 8.8.8.8 pingen direkt von der pfSense (Diagnostics)

ja / auch mit google.com

* Kannst du die 8.8.8.8 pingen direkt vom MT ?

ja / auch mit google.com

* Kannst du die 8.8.8.8 vom MT tracerouten (Traceroute) ?

ja / auch mit google.com

DNS im MT ist die 192.168.1.1 Dynamisch vom DHCP client (Allow Remote Requests) ist gesetzt.

Der DNS Server im Client ist auch falsch !
Die MT ist kein DNS Proxy ! Hier musst du im DHCP Server auf dem MT zwingend die 192.168.1.1 einsetzen (pfSense IP) denn die ist DNS Proxy !
Die Clients mussen die 192.168.1.1. als DNS Server bekommen.

Der Fehler liegt aber woanderes, denn wenn du von einem Client schon nicht die 8.8.8.8 pingen kannst greift irgendwo einen falsche FW Regel oder dein Routing stimmt nicht...

Weitere Checks:

Kannst du die 192.168.1.1 pingen von einem Client in den 172.16er Subnetzen ?
Was sagt ein tracert -d 8.8.8.8 von einem Client ? Wo bleibt der hängen ?
Lösche das Firewall Log in der pfSense und wiederhole den Traceroute oder den Ping auf die 8.8.8.8 ! Siehst du dort irgendwelche Meldungen das was geblockt wird ?

Zitat von @aqui:

Der DNS Server im Client ist auch falsch !
Die MT ist kein DNS Proxy ! Hier musst du im DHCP Server auf dem MT zwingend die 192.168.1.1 einsetzen (pfSense IP) denn die
ist DNS Proxy !

Dem muss ich widersprechen. Er hat auf dem MK die Option gesetzt "Allow Remote requests" indem Fall ist der MK DNS-Proxy

Der Grund kann es aber wie schon von dir gesagt nicht sein wenn er noch nicht mal die 8.8.8.8 pingen kann.

Ein tracert sollte die sagen wo es hängt...

Irgendwas ist da in der pfSense noch nicht ganz koscher so meine Vermutung. Die Logs sollten das aber aufklären.

Gruß jodel32

hab ich angepasst.

Weitere Checks:

Kannst du die 192.168.1.1 pingen von einem Client in den 172.16er Subnetzen ?

* Was sagt ein tracert -d 8.8.8.8 von einem Client ? Wo bleibt der hängen ?

1 <1 ms <1 ms < 1ms 172.1.3.1
2 <1 ms <1 ms < 1ms 192.168.1.1
3 * * * Zeitüberschr....
4 * * * Zeitüberschr....

* Lösche das Firewall Log in der pfSense und wiederhole den Traceroute oder den Ping auf die 8.8.8.8 ! Siehst du dort
irgendwelche Meldungen das was geblockt wird ?

Wie sehen die WAN-Firewall-Regeln aus ?
Ich vermute sehr stark das da der Hund begraben ist ...

Ist die pfSense direkt mit einem transparenten NUR Modem am Internet ?? (Öffentliche IP direkt am WAN Port !)
Oder ist da noch ein NAT Router in der Kaskade dazwischen ?
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät

Und Firewall > NAT > Outbound ?
Wenn dort nur das pfSense Subnetz zum Masquerading eingetragen ist musst du deine anderen Mikrotik-Netze dort ebenfalls fürs Masqerading aktivieren.
Sollte da noch ein anderer Router am WAN davor hängen muss die Bogus-Network Regel weg.

Dort sollte "Automatic NAT Outbound Rule Generation" angehakt sein !

Zitat von @aqui:

Ist die pfSense direkt mit einem transparenten NUR Modem am Internet ?? (Öffentliche IP direkt am WAN Port !)

ja , PPOE an FiberModem

Also wenn du dir die Interface Übersicht ansiehst dann siehst du ort eine öffentliche IP am WAN Port ??
Oder siehst du da eine private RFC 1918 IP ??

An der NAT Outbound Rule (siehe oben) hast du nichts verändert ?

Zitat von @aqui:

Dort sollte "Automatic NAT Outbound Rule Generation" angehakt sein !

ist angehakt

Zitat von @aqui:

Also wenn du dir die Interface Übersicht ansiehst dann siehst du ort eine öffentliche IP am WAN Port ??

Da steht die öffentliche IP.

An der NAT Outbound Rule (siehe oben) hast du nichts verändert ?

nein (factory default)

Schmeiss mal die Sniffer Funktion auf der pfSense an und schneide diese ICMP Pakete mal mit die aus den Subnetzen kommen.
Ein kurzer Testaufbau hier im Labor hat auf Anhieb fehlerfrei funktioniert mit einem MT RB750 ohne großartige Konfig mit fast allem im Default.
Irgendwo hast du da noch einen Kinken eingebaut...?!

Zitat von @aqui:

Schmeiss mal die Sniffer Funktion auf der pfSense an und schneide diese ICMP Pakete mal mit die aus den Subnetzen kommen.
Ein kurzer Testaufbau hier im Labor hat auf Anhieb fehlerfrei funktioniert mit einem MT RB750 ohne großartige Konfig mit
fast allem im Default.
Irgendwo hast du da noch einen Kinken eingebaut...?!

ping vom client

10:02:56.599248 IP 172.1.3.253 > 8.8.8.8: ICMP echo request, id 1, seq 137, length 40
10:03:01.251974 IP 172.1.3.253 > 8.8.8.8: ICMP echo request, id 1, seq 138, length 40
10:03:04.574947 IP 172.1.3.253.57598 > 192.168.100.116.161: UDP, length 78
10:03:04.574987 IP 172.1.3.253.57598 > 192.168.100.116.161: UDP, length 78
10:03:04.575062 IP 172.1.3.253.57598 > 192.168.100.13.161: UDP, length 78
10:03:04.575088 IP 172.1.3.253.57598 > 192.168.100.14.161: UDP, length 78
10:03:06.260061 IP 172.1.3.253 > 8.8.8.8: ICMP echo request, id 1, seq 139, length 40
10:03:11.252514 IP 172.1.3.253 > 8.8.8.8: ICMP echo request, id 1, seq 140, length 40

woher sind die 100 ????

Das ist eine gute Frage ! Das Netzwerk musst du ja irgendwo willentlich konfiguriert haben.
UDP 161 ist SNMP (Management) der Client 172.1.3.253 versucht einen SNMP Server mit der IP 192.168.100.116 zu erreichen. Ist ja aus dem Trace klar ersichtlich.... Das musst du so also auf dem Client konfiguriert haben.

Für unser Problem ist aber Fakt das gar kein Antwortpaket (ICMP Reply) vom Host 8.8.8.8 zurückkommt.
Was wieder die Vermutung aufwirft das irgendeine Regel am WAN Port zuschlägt...

Ich mess das nochmal genau hier im Labor im Testsetup....

Nachdem ich die Regel Eintragen habe komme ich durch ...

Kann ich das so belassen?

Nachdem ich die Regel Eintragen habe komme ich durch ...

Deswegen habe ich ja gleich gesagt, keine Automatik nehmen

und gleich überprüfen ob die Netze geNATed werden ...

Kann ich das so belassen?

Les dich mal zu NAT ein damit du überhaupt verstehst was NAT macht, dann kannst du es auch selber einschätzen und musst nicht nur anderen vertrauen

So wie ich das nach dem durchforsten des NAT wiki Verstanden habe, ist SNAT ein übliches (verbreitetes) vorgehen...

Zitat von @fredfred:

So wie ich das nach dem durchforsten des NAT wiki Verstanden habe, ist SNAT ein übliches (verbreitetes) vorgehen...

Klar das musst du mir nicht sagen..., wollte ja nur das du dich auch mal schlau machst bevor wir dir hier alles vorbeten müssen

SNAT (Masquerading) brauchst du immer wenn du von einem privaten Subnetz ins Internet willst, denn du hast ja nur eine öffentliche IP aber mehrere Clients die ins Netz wollen, deswegen wird bei den ausgehenden Paketen die Quell(SRC)-Addresse durch deine öffentliche IP-Adresse ersetzt und auf dem Rückweg setzt die pfSense das Ziel wieder auf die passende IP des Clients, dazu hat die PFsense eine NAT-Tabelle in der diese Verbindungen festgehalten werden und sie so die Zuordnung vornehmen kann.

Firewall-Grundlagen eben.

Bitte den Beitrag dann noch als gelöst markieren.

Na ja das ganze Ansinnen ist schon etwas grotesk mit 172.er und 192.168er IP netzadressen ohne NAT ins Internet zu wollen. Technisch ist das die Quadratur des Kreises und damit unmöglich, denn diese RFC 1918 IP Netze werden an jedem Provider Zugangspunkt beblockt und gedropt.
Die NAT Outbound Regeln bezeichnen kryptischerweise ISAKMP also ein Protokollteil von IPsec (es fehlt aber ESP).
Was das alles mit der ursprünglichen Fragestellung zu tun hat bleibt schleierhaft und diffus. Genu wie der eigentliche Sinn dieses Unterfangens.
Aber nundenn...wenn es mit geheimnisvoller Frickelei die was auch immer fixt, jetzt klappt umso besser.
Da fehlt dann in der Tat nur noch:
How can I mark a post as solved?

Ich meinte hier irgendwo gelesen zu haben "doppeltes" NAT sei nicht ideal.

Darum sollte dies nur die Pfsense erledigen...

Der Titel "Routing ohne NAT" ist demnach falsch gewählt.

Das stimmt !
Doppeltes NAT ist überflüssig, da kontraproduktiv aus Performance Sicht und sollte man wenn immer möglich auch vermeiden. Sorry, dann hatte ich das missverstanden denn damit meintest du vermutlich das NAT einzig nur auf dem MT Router, richtig ?
Ja klar, das gehört unbedingt AUS und das kann logischerweise zentral die pfSense machen.
Dennoch bleibt es aber schleierhaft was die IPsec Regeln da bewirken sollen. VPN hat mit der eigentlichen Fragestellung ja rein gar nix zu tun. ?!

Zitat von @aqui:

damit meintest du vermutlich das NAT einzig nur auf dem MT Router, > richtig ?
Genau

Ja klar, das gehört unbedingt AUS und das kann logischerweise zentral die pfSense machen.
Dennoch bleibt es aber schleierhaft was die IPsec Regeln da bewirken sollen. VPN hat mit der eigentlichen Fragestellung ja rein
gar nix zu tun. ?!

Du meinst diesen Screenshot ?

Diese zwei Regeln werden von der Pfsense glaube ich per default erstellt , ich habe lediglich die oberste Regel hinzugefügt

Besten Dank für Eure Hilfe !!!

Auf dem Mikrotik gehört NAT aus und auf der PFSense ein, feddich, nix doppeltes NAT also, dafür hast du ja extra die statischen Routen angelegt ! Also alles ganz logisch wenn man mal nachdenken würde.

Wenn du kein IPSec VPN betreibst kannst du diese NAT-Outbound-Regeln auf Port 500 löschen.
Also brauchst nur die erste, dritte und die letzte Regel aus deinem Screenshot.

German solved Question MikroTik Other systems

Hotly discussed

How to set up and configure a Linux GRE tunnelAlexWisha - 3 Comments

End of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment