14
Eingehenden SMTP-Traffic über VPN routen
Hallo,
es geht um Folgendes:
Zwei Standorte, Internetzugang jeweils über einen Mikrotik:
A) Subnetz 192.168.100.0/24
B) Subnetz 172.21.79.0/24
Beide Standorte haben ein funktionstüchtiges IPsec-VPN, Traffic zwischen den Subnetzen funktioniert problemlos in beide Richtungen.
Nun soll ein Exchange-Server an Standort B (IP 172.21.79.10) in Betrieb genommen werden, wobei dieser Mails direkt annehmen soll (also ohne POP3-Konnektor).
Jetzt die Besonderheit: Der MX soll nicht auf die WAN IP von B gehen, sondern von A, d.h. eingehende Mails sollen von A über das VPN an den Exchange an Standort B geleitet werden. Ein anderes Konstrukt kommt aus verschiedenen Gründen nicht in Frage.
Aktuell ist das IPsec ohne L2TP konfiguriert. Als Src. Address ist das jeweilige LAN konfiguriert (bei Router A LAN A), als Dst. Address das Subnetz der Gegenseite (bei Router A LAN B).
Wie würdest Ihr die Anforderung umsetzen?
Braucht es zwingend L2TP (oder ggf. ein anderes Protokoll) oder kommt man mit weiteren IPsec-Policies ans Ziel? Wie ist das Port Forwarding + Routing umzusetzen?
Hättet Ihr konkrete Lösungsansätze / Tutorials?
Vielen Dank und einen schönen Sonntag,
tantalos
es geht um Folgendes:
Zwei Standorte, Internetzugang jeweils über einen Mikrotik:
A) Subnetz 192.168.100.0/24
B) Subnetz 172.21.79.0/24
Beide Standorte haben ein funktionstüchtiges IPsec-VPN, Traffic zwischen den Subnetzen funktioniert problemlos in beide Richtungen.
Nun soll ein Exchange-Server an Standort B (IP 172.21.79.10) in Betrieb genommen werden, wobei dieser Mails direkt annehmen soll (also ohne POP3-Konnektor).
Jetzt die Besonderheit: Der MX soll nicht auf die WAN IP von B gehen, sondern von A, d.h. eingehende Mails sollen von A über das VPN an den Exchange an Standort B geleitet werden. Ein anderes Konstrukt kommt aus verschiedenen Gründen nicht in Frage.
Aktuell ist das IPsec ohne L2TP konfiguriert. Als Src. Address ist das jeweilige LAN konfiguriert (bei Router A LAN A), als Dst. Address das Subnetz der Gegenseite (bei Router A LAN B).
Wie würdest Ihr die Anforderung umsetzen?
Braucht es zwingend L2TP (oder ggf. ein anderes Protokoll) oder kommt man mit weiteren IPsec-Policies ans Ziel? Wie ist das Port Forwarding + Routing umzusetzen?
Hättet Ihr konkrete Lösungsansätze / Tutorials?
Vielen Dank und einen schönen Sonntag,
tantalos
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3115439691
Url: https://administrator.de/contentid/3115439691
Ausgedruckt am: 25.11.2024 um 11:11 Uhr
14 Kommentare
Neuester Kommentar
Da kommt man eigentlich als Admin auch selbst drauf. 😉
Einfach mit einem simplen Port Forwarding von TCP 25, 465, 587 am A WAN Port dessen Zieladresse dann die IP des Exchange Servers im Netz von B ist.
Hier einmal als Beispiel mit einem PFW von UDP 51820
Aber Achtung das der Rücktraffic des Exchange Servers dann nicht via B zurück an den Client (SMTP Initiator) geht sondern ebenfalls über den VPN Tunnel via A andernfalls hast du ein Problem.
Diesen Fall hatten wir hier im Forum kürzlich erst mit einem gleichen Szenario:
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Einfach mit einem simplen Port Forwarding von TCP 25, 465, 587 am A WAN Port dessen Zieladresse dann die IP des Exchange Servers im Netz von B ist.
Hier einmal als Beispiel mit einem PFW von UDP 51820
Aber Achtung das der Rücktraffic des Exchange Servers dann nicht via B zurück an den Client (SMTP Initiator) geht sondern ebenfalls über den VPN Tunnel via A andernfalls hast du ein Problem.
Diesen Fall hatten wir hier im Forum kürzlich erst mit einem gleichen Szenario:
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Hallo aqui,
danke für Deine Nachricht.
In einem Test-Setup hatte ich es genau so gemacht, ohne Erfolg. Der Traffic floss nicht über das VPN, sondern wurde vom Tik A wieder über sein WAN-Interface rausgeschickt.
Die IPsec-Policy ist in A wie folgt:
Da der eingehende Request ja von einer externen IP und nicht von einer aus LAN A kommt, greift die Policy nicht, weil die Src-Bedingung nicht erfüllt ist. Daher wird der Traffic über die default-Route, mithin übers WAN-Interface von A rausgesendet und landet im Nirvana. Er kommt also über WAN A rein und geht auch gleich wieder über WAN A raus.
Hast Du eine Idee, wie ich den eingehenden Traffic durch das VPN schicken kann?
Und wie kann ich die Antwort-Pakete des Exchange-Servers dazu bringen, nicht die default-Route von B zu nehmen, sondern ebenfalls durch den Tunnel zu gehen?
Schöne Grüße,
tantalos
danke für Deine Nachricht.
In einem Test-Setup hatte ich es genau so gemacht, ohne Erfolg. Der Traffic floss nicht über das VPN, sondern wurde vom Tik A wieder über sein WAN-Interface rausgeschickt.
Die IPsec-Policy ist in A wie folgt:
Da der eingehende Request ja von einer externen IP und nicht von einer aus LAN A kommt, greift die Policy nicht, weil die Src-Bedingung nicht erfüllt ist. Daher wird der Traffic über die default-Route, mithin übers WAN-Interface von A rausgesendet und landet im Nirvana. Er kommt also über WAN A rein und geht auch gleich wieder über WAN A raus.
Hast Du eine Idee, wie ich den eingehenden Traffic durch das VPN schicken kann?
Und wie kann ich die Antwort-Pakete des Exchange-Servers dazu bringen, nicht die default-Route von B zu nehmen, sondern ebenfalls durch den Tunnel zu gehen?
Schöne Grüße,
tantalos
Da der eingehende Request ja von einer externen IP und nicht von einer aus LAN A kommt, greift die Policy nicht
Genau DESHALB ja auch der obige Warnhinweis am Ende mit dem Hinweis das du außer dem Destination NAT auch noch zusätzlich ein Outbound NAT an A machen musst um eben Source und Destination Adressen anzupassen!! Kollege @colinardo erklärt es dort im Detail anhand eines Paket Flows.Leider hast du diese beiden Links wohl nicht gelesen. Dann nützt natürlich auch das beste Forum nix wenn du Hilfen schlicht ignorierst.
SNAT und SMTP ist aber eine sehr, sehr dumme Idee. Viele Anti-Spam-Prüfungen hängen an der IP des einlieferndes Systems. Und auf die will man an sich nicht verzichten.
2
Moin,
Mal kurz gefragt: an Standort A existiert aber kein Exchange/ Mail-Server, oder?
Gruß
em-pie
Mal kurz gefragt: an Standort A existiert aber kein Exchange/ Mail-Server, oder?
Gruß
em-pie
Moin,
ungefilterte Datenverkehr einmal quer durch das LAN und sogar noch durch einen VPN-Tunnel.
Was ist aus der guten alten DMZ geworden? Macht man das heute nicht mehr?
@LordGurke
Gruß,
Dani
ungefilterte Datenverkehr einmal quer durch das LAN und sogar noch durch einen VPN-Tunnel.
Was ist aus der guten alten DMZ geworden? Macht man das heute nicht mehr?
@LordGurke
SNAT und SMTP ist aber eine sehr, sehr dumme Idee
In dem obengenannten Zusammenhang, nämlich für ausgehende E-Mails, ist SNAT unabdinglich.Gruß,
Dani
1Zitat von @Dani:
@LordGurke
@LordGurke
SNAT und SMTP ist aber eine sehr, sehr dumme Idee
In dem obengenannten Zusammenhang, nämlich für ausgehende E-Mails, ist SNAT unabdinglich.Ich verstehe die Fragestellung so, dass es um eingehende Mails geht. Und da kann ich von SNAT nur abraten, weil man sich damit auch interessante Sicherheitslücken aufreißt (z.B. Relaying ist für interne IPs erlaubt, was bei SNAT dann immer greift).
@LordGurke
Gruß,
Dani
Ich verstehe die Fragestellung so, dass es um eingehende Mails geht.
Das wäre dann aber nicht DNAT, oder? Da sehe ich absolut keine Probleme...weil diese "Umsetzung" keinsterweise in Header der empfangener E-Mail auftaucht. Der Exchange-Server sieht problemlos die IP-Adresse des Absenders.Gruß,
Dani
1
Hallo,
ich bin mir sicher, dass man Exchangerollen in einer via VPN verbundenen Domäne sauber über mehrere Standorte verteilen kann.
Alles Andere ist Frickelkram.
Insbesondere dann, wenn es „nur“ darum geht, die 99 Cent im Monat für 'ne statische IP zu sparen
Gruß,
Jörg
ich bin mir sicher, dass man Exchangerollen in einer via VPN verbundenen Domäne sauber über mehrere Standorte verteilen kann.
Alles Andere ist Frickelkram.
Insbesondere dann, wenn es „nur“ darum geht, die 99 Cent im Monat für 'ne statische IP zu sparen
Gruß,
Jörg
Zitat von @em-pie:
Moin,
Mal kurz gefragt: an Standort A existiert aber kein Exchange/ Mail-Server, oder?
Gruß
em-pie
Moin,
Mal kurz gefragt: an Standort A existiert aber kein Exchange/ Mail-Server, oder?
Gruß
em-pie
Nein.
Zitat von @LordGurke:
SNAT und SMTP ist aber eine sehr, sehr dumme Idee. Viele Anti-Spam-Prüfungen hängen an der IP des einlieferndes Systems. Und auf die will man an sich nicht verzichten.
SNAT und SMTP ist aber eine sehr, sehr dumme Idee. Viele Anti-Spam-Prüfungen hängen an der IP des einlieferndes Systems. Und auf die will man an sich nicht verzichten.
Mit der dst-nat-Regel in Verbindung mit einer zusätzlichen src-nat-Regel, die die remote IP auf eine im Subnetz von A umschreibt und somit die IPsec policy greift, habe ich es jetzt zum Laufen bekommen.
Dein Einwand ist gewichtig, also habe ich es versucht über IPsec Policies zu lösen, was leider nicht funktioniert:
Router A (responder):
/ip ipsec policy
add dst-address=172.21.79.0/24 peer=peer1 proposal=aes256_sha512_PFS2048 src-address=192.168.100.0/24 tunnel=yes
add dst-address=172.21.79.10/32 dst-port=25 peer=peer1 proposal=aes256_sha512_PFS2048 protocol=tcp src-address=0.0.0.0/0 tunnel=yes
add dst-address=172.21.79.10/32 dst-port=465 peer=peer1 proposal=aes256_sha512_PFS2048 protocol=tcp src-address=0.0.0.0/0 tunnel=yes
add dst-address=172.21.79.10/32 dst-port=587 peer=peer1 proposal=aes256_sha512_PFS2048 protocol=tcp src-address=0.0.0.0/0 tunnel=yesRouter B (initiator):
/ip ipsec policy
add dst-address=192.168.100.0/24 peer=peer1 proposal=aes256_sha512_PFS2048 src-address=172.21.79.0/24 tunnel=yes
add dst-address=0.0.0.0/0 peer=peer1 proposal=aes256_sha512_PFS2048 protocol=tcp src-address=172.21.79.10/32 src-port=25 tunnel=yes
add dst-address=0.0.0.0/0 peer=peer1 proposal=aes256_sha512_PFS2048 protocol=tcp src-address=172.21.79.10/32 src-port=465 tunnel=yes
add dst-address=0.0.0.0/0 peer=peer1 proposal=aes256_sha512_PFS2048 protocol=tcp src-address=172.21.79.10/32 src-port=587 tunnel=yesAction ist jeweils: encrypt / require / esp / proposal wie oben.
Habt Ihr Ideen, woran es haken könnte?
Dein Einwand ist gewichtig, also habe ich es versucht über IPsec Policies zu lösen, was leider nicht funktioniert:
Welchen Einwand von WEM oben meinst du denn?? Du sprichst in Rätseln? Mit IPsec Policies zu lösen ist Unsinn und nicht möglich es muss schon NAT sein. Das Warum erklärt ja der Paket Flow im oben zitierten Thread umfassend im Detail. Die Thematik des Kollegen @LordGurke ist von der rein netzwerktechnischen Lösung ja erstmal entkoppelt.Aber wenns nun alles klappt, wie du selber sagst, ist doch dann alles gut!
Zitat von @aqui:
Dein Einwand ist gewichtig, also habe ich es versucht über IPsec Policies zu lösen, was leider nicht funktioniert:
Welchen Einwand von WEM oben meinst du denn?? Du sprichst in Rätseln?Den Einwand von @LordGurke, den ich zitierte.
Mittlerweile habe ich es mit DNAT + IPsec Policies gelöst.
Vielen Dank an alle.
Mittlerweile habe ich es mit DNAT + IPsec Policies gelöst.
👍Bitte dann auch deinen Thread hier als erledigt markieren !!
