20
Zwischen Miktrotik und PFSense GRE Tunnel mit IPSec Verschlüsslung
Hallo zusammen,
und ein frohes neues Jahr.
Ich habe ein Problem mit einem GRE Tunnel und der IPSec Transport Verschlüsselung.
Wenn der GRE-Tunnel ohne IPSec Verschlüsselung aufgebaut wird funktioniert die Kommunikation in alle Richtungen.
Pings und TCP/UDP Verbindungen funktionieren ohne Probleme in allen Richtungen und von Jedem Standort.
Sobald die IPSec Verbindung aufgebaut wurde können die Teilnehmer in Standort A und Standort B weiterhin mit einem Ping von allen Seiten erreicht werden.
Allerdings funktionieren Die TCP/UDP Verbindungen nur noch ausgehend von Standort A, der Zugriff von Standort B ist nicht mehr möglich. An was könnte es liegen, Firewall oder IPSec Konfiguration?
Hier der Grundsätzliche Aufbau.
Standort A:
PFSense Firewall mit neuster Version.
WAN, LAN und OPT1 als GRE Interface sind vorhanden.
WAN Schnittstelle mit Statischer Public IP und Öffentliches /29 Subnetz.
Das Public Subnetz funktioniert als 1:1 NAT auf Lokale Server Dienste.
WAN: 176.9.104.XXX, 176.9.200.XXX/29
LAN: 192.168.1.0/24
OPT1: 172.16.1.0/30 Lokaler Tunnel IP 172.16.1.1
Standort B:
Mikrotik Hardware Hex Router V6.43.7 WAN, LAN, DMZ
WAN: 213.157.15.XXX
LAN: 192.168.10.0/24
DMZ: 192.168.80.0/22
GRE-Tunnel: 172.16.1.2
Teilweise habe ich in der PFSense Firewall folgende Block meldungen.
Habe schon alle möglichen einstellungen versucht, bekomme die Meldungen aber nicht weg.
Könnte das mit meinem Problem zu tun haben und Welcher Informationen werden noch benötigt?
@6(1000000104) block drop out log inet all label "Default deny rule IPv4"
Vieleicht kann mir auch noch einer die bedeutung vom Pfeil vor der Schnittstelle auf dem Bild erklären?
Schonmal vielen Dank für eure Unsterstützung.
und ein frohes neues Jahr.
Ich habe ein Problem mit einem GRE Tunnel und der IPSec Transport Verschlüsselung.
Wenn der GRE-Tunnel ohne IPSec Verschlüsselung aufgebaut wird funktioniert die Kommunikation in alle Richtungen.
Pings und TCP/UDP Verbindungen funktionieren ohne Probleme in allen Richtungen und von Jedem Standort.
Sobald die IPSec Verbindung aufgebaut wurde können die Teilnehmer in Standort A und Standort B weiterhin mit einem Ping von allen Seiten erreicht werden.
Allerdings funktionieren Die TCP/UDP Verbindungen nur noch ausgehend von Standort A, der Zugriff von Standort B ist nicht mehr möglich. An was könnte es liegen, Firewall oder IPSec Konfiguration?
Hier der Grundsätzliche Aufbau.
Standort A:
PFSense Firewall mit neuster Version.
WAN, LAN und OPT1 als GRE Interface sind vorhanden.
WAN Schnittstelle mit Statischer Public IP und Öffentliches /29 Subnetz.
Das Public Subnetz funktioniert als 1:1 NAT auf Lokale Server Dienste.
WAN: 176.9.104.XXX, 176.9.200.XXX/29
LAN: 192.168.1.0/24
OPT1: 172.16.1.0/30 Lokaler Tunnel IP 172.16.1.1
Standort B:
Mikrotik Hardware Hex Router V6.43.7 WAN, LAN, DMZ
WAN: 213.157.15.XXX
LAN: 192.168.10.0/24
DMZ: 192.168.80.0/22
GRE-Tunnel: 172.16.1.2
Teilweise habe ich in der PFSense Firewall folgende Block meldungen.
Habe schon alle möglichen einstellungen versucht, bekomme die Meldungen aber nicht weg.
Könnte das mit meinem Problem zu tun haben und Welcher Informationen werden noch benötigt?
@6(1000000104) block drop out log inet all label "Default deny rule IPv4"
Vieleicht kann mir auch noch einer die bedeutung vom Pfeil vor der Schnittstelle auf dem Bild erklären?
Schonmal vielen Dank für eure Unsterstützung.
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: 397059
Url: https://administrator.de/forum/zwischen-miktrotik-und-pfsense-gre-tunnel-mit-ipsec-verschluesslung-397059.html
Ausgedruckt am: 22.12.2024 um 01:12 Uhr
20 Kommentare
Neuester Kommentar
Grundlagen der Mikrotik Konfig für das Design findest du hier:
Routing Frage welches Protokoll für Mobile Geräte
Die Ursache ist schwer zu beurteilen, da man weder deine genaue MT Konfig noch die der pfSense kennt.
Was auch etwas unklar ist, ist deine Adressierung am OPT1 Interface. Das /30er Netz lässt nur 2 Host IP Adressen zu. Wenn du aber nun das OPT1 Interface und das Tunnel Interface bzw. das Tunnel Interface auf MT Seite hast wären das ja schon 3.
Ich würde den Pfeil so interpretieren das diese Daten inbound am OPT1 Interface auflaufen. Was dann aber deiner oben angegebenen IP Adressierung widerspricht. Es sei denn....du hast einen Fehler beim Stecken der Patchkabel gemacht und bist mit den Interfaces in einem falschen IP Segment...?!
Ich versuche mal das Setup im Labor nachzustellen.
Routing Frage welches Protokoll für Mobile Geräte
Die Ursache ist schwer zu beurteilen, da man weder deine genaue MT Konfig noch die der pfSense kennt.
Was auch etwas unklar ist, ist deine Adressierung am OPT1 Interface. Das /30er Netz lässt nur 2 Host IP Adressen zu. Wenn du aber nun das OPT1 Interface und das Tunnel Interface bzw. das Tunnel Interface auf MT Seite hast wären das ja schon 3.
Ich würde den Pfeil so interpretieren das diese Daten inbound am OPT1 Interface auflaufen. Was dann aber deiner oben angegebenen IP Adressierung widerspricht. Es sei denn....du hast einen Fehler beim Stecken der Patchkabel gemacht und bist mit den Interfaces in einem falschen IP Segment...?!
Ich versuche mal das Setup im Labor nachzustellen.
Ich scheitere schon daran die IPsec Transport Verbindung hinzubekommen 
Mikrotik nutzt sofern du das GRE Interface gleich mit "IPsec Secret" konfigurierst automatisch eine IPsec Transport Encryption im Main Mode.
Soweit so gut. Konfiguriert man das auf der pfSense Seite auch kommt zwar im IPsec Status die VPN Verbindung auch mit "Established" hoch, aber sie ist es nicht. Wenn du dir im Dashboard das IPsec Status Widget installierst siehst du auch das dort die Verbindung auf Down geht.
Das IPsec Log sagt das ebenso und wenn man sich im Status mal die SAs ansieht werden da keine ausgetauscht. Geht also nicht.
Außerdem gibt es einen aktuellen Bug mit IPsec Transport und GRE Tunnel in der pfSense:
https://redmine.pfsense.org/issues/4479
Das Target Release für den Fix ist die 2.4.5. Aktuell ist die 2.4.4_P1
Versteht man das richtig geht es derzeit nur mit Floating Regeln in der pfSense als Workaround.
Eine Anleitung dazu findet man hier:
https://aspel.github.io/2018-11-19/ospf-over-gre-tunnel-with-ipsec-mikro ...
Vielleicht beschreibst du mal kurz dein IPsec Setup oder postest die Screenshots hier ?!
Mikrotik nutzt sofern du das GRE Interface gleich mit "IPsec Secret" konfigurierst automatisch eine IPsec Transport Encryption im Main Mode.
Soweit so gut. Konfiguriert man das auf der pfSense Seite auch kommt zwar im IPsec Status die VPN Verbindung auch mit "Established" hoch, aber sie ist es nicht. Wenn du dir im Dashboard das IPsec Status Widget installierst siehst du auch das dort die Verbindung auf Down geht.
Das IPsec Log sagt das ebenso und wenn man sich im Status mal die SAs ansieht werden da keine ausgetauscht. Geht also nicht.
Außerdem gibt es einen aktuellen Bug mit IPsec Transport und GRE Tunnel in der pfSense:
https://redmine.pfsense.org/issues/4479
Das Target Release für den Fix ist die 2.4.5. Aktuell ist die 2.4.4_P1
Versteht man das richtig geht es derzeit nur mit Floating Regeln in der pfSense als Workaround.
Eine Anleitung dazu findet man hier:
https://aspel.github.io/2018-11-19/ospf-over-gre-tunnel-with-ipsec-mikro ...
Vielleicht beschreibst du mal kurz dein IPsec Setup oder postest die Screenshots hier ?!
1
Hi Aqui,
hey super danke für deine Hilfe du hast mir eine kleinigkeit gezeigt die den fehler behoben hat.
Ich habe in dem von dir geposteten Link "https://aspel.github.io/2018-11-19/ospf-over-gre-tunnel-with-ipsec-mikrotik-and-pfsense-and-two-isp"
die Firewall so eingestellt wie dort beschrieben und schon funktioniert die verbindung.
Dafür vielen dank!
Das Problem mit der IPSec verbindung hatte ich auch, wenn man die IPSec verschlüsselung über den GRE Tunnel einstelle.
Daher habe ich die Einstellungen manuel getroffen.
Hier ein paar bilder von meiner Konfiguration.
vielen Dank
Gruß Wienni
Mikrotik
PFSense
hey super danke für deine Hilfe du hast mir eine kleinigkeit gezeigt die den fehler behoben hat.
Ich habe in dem von dir geposteten Link "https://aspel.github.io/2018-11-19/ospf-over-gre-tunnel-with-ipsec-mikrotik-and-pfsense-and-two-isp"
die Firewall so eingestellt wie dort beschrieben und schon funktioniert die verbindung.
Dafür vielen dank!
Das Problem mit der IPSec verbindung hatte ich auch, wenn man die IPSec verschlüsselung über den GRE Tunnel einstelle.
Daher habe ich die Einstellungen manuel getroffen.
Hier ein paar bilder von meiner Konfiguration.
vielen Dank
Gruß Wienni
Mikrotik
Cool ! Glückwunsch ! 
Das ist eine sehr interessante Konfig im VPN Umfeld, weil man damit dynamisch routen kann und so auch auf Link Ausfälle automatisch reagieren kann. Ebenso kann man Multicast Inhalte (Audio, Video) darüber routen.
Deshalb will ich das auch hier unbedingt auch zum Fliegen bekommen in einem gemischten Umfeld mit der pfSense. Rein mit MT ist das ja kein Thema und funktioniert out of the Box. Siehe hier:
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Ein paar Fragen zu deiner Konfig um das Rad hier nicht neu erfinden zu müssen
:
Eine wichtige Sache im IPsec Profil ist mir noch aufgefallen:
Du hast ja alles auf 3DES laufen. Auch da muss die MT Seite umgestellt werden, denn 3DES ist dort gar nicht ausgewählt als Cipher Suite.
Das hat einen guten Grund, denn 3DES und SHA1 gilt als unsicher. Besser man geht auf AES mit AES-GCM.
Wenn möglich wäre es hilfreich wenn du das nochmal testen könntest ob das auch klappt.
AES-GCM 128 und 256 anhaken, Hash auf AES256.
Macht den Tunnel etwas sicherer.
Wenn du das FRR Package in der pfSense installierst und im MT unter Routing - OSPF das GRE Netz ins Routing einträgst kannst du über den GRE Tunnel dynamisch routen !
Das ist eine sehr interessante Konfig im VPN Umfeld, weil man damit dynamisch routen kann und so auch auf Link Ausfälle automatisch reagieren kann. Ebenso kann man Multicast Inhalte (Audio, Video) darüber routen.
Deshalb will ich das auch hier unbedingt auch zum Fliegen bekommen in einem gemischten Umfeld mit der pfSense. Rein mit MT ist das ja kein Thema und funktioniert out of the Box. Siehe hier:
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Ein paar Fragen zu deiner Konfig um das Rad hier nicht neu erfinden zu müssen
:- GRE Tunnel MT: Warum hast du da keine "Local Adress" angegeben? Das ist in der Regel doch Point2Point Verbindungen. Dort müsste doch die 213er IP stehen...eigentlich ?!
- IPsec Policy: Die beiden Adressen 213... und 176... sind die jeweiligen WAN Ports, richtig ? Warum hast du da "all(255)" als Protokoll drin ? Macht es nicht Sinn das auf 47 zu setzen. GRE ist IP Prot. Nummer 47 Alles andere soll ja NICHT in den IPsec Tunnel
- Hast du die IPsec Policies und Peers manuell eingerichtet ?? Oder hast du das automatisiert machen lassen durch Definition des "IPsec Secret" Passwords in der GRE Interface Konfig ?
- Wenn du das IPsec Widget im Dashboard der pfSense installierst kannst du den VPN Tunnel dort im Status "UP" sehen ?
Eine wichtige Sache im IPsec Profil ist mir noch aufgefallen:
- Die pfSense nutzt das etwas sicherere AES-GCM als Encryption per Default in der Phase 1, der Mikrotik ist aber im Default auf AES-CBC eingestellt. Hast du das im MT entsprechend umgestellt auf AES-GCM ? (Sorry, sehe gerade du machst 3DES)
Du hast ja alles auf 3DES laufen. Auch da muss die MT Seite umgestellt werden, denn 3DES ist dort gar nicht ausgewählt als Cipher Suite.
Das hat einen guten Grund, denn 3DES und SHA1 gilt als unsicher. Besser man geht auf AES mit AES-GCM.
Wenn möglich wäre es hilfreich wenn du das nochmal testen könntest ob das auch klappt.
AES-GCM 128 und 256 anhaken, Hash auf AES256.
Macht den Tunnel etwas sicherer.
Wenn du das FRR Package in der pfSense installierst und im MT unter Routing - OSPF das GRE Netz ins Routing einträgst kannst du über den GRE Tunnel dynamisch routen !
1
Danke für deinen Hinweis mit der verschlüsslung.
Habe die einstellungen Angepasst und der Tunnel funktioniert noch weiterhin.
Durch das testen habe ich da einfache einstellungen verwendet.
Mit dem Dynamischen Routen werde ich mich dan als nächstes beschäftigen.
Hast du dazu schon erfahrung? vieleicht könntest du mir da auch weiter helfen!
Zu deinen fragen noch:
Habe ich nocht nachträglich eingetragen funktioniert mit oder ohne. Ist warscheinlich erst relevant wenn der Router mehrere WAN Adressen besitzt das die ausgangsadresse immer gleich bleibt.
Das habe ich auch schon mit 47 getestet dann kommt in Phase 2 keine verbindung zu stande.
Ja die IPsec Policies und Peers habe ich manuell eingerichtet, da es mit der PFSens konfiguration nicht hingehauen hat.
Ja das funktioniert auch!
Gruß Wienni
Habe die einstellungen Angepasst und der Tunnel funktioniert noch weiterhin.
Durch das testen habe ich da einfache einstellungen verwendet.
Mit dem Dynamischen Routen werde ich mich dan als nächstes beschäftigen.
Hast du dazu schon erfahrung? vieleicht könntest du mir da auch weiter helfen!
Zu deinen fragen noch:
Zitat von @aqui:
"GRE Tunnel MT: Warum hast du da keine "Local Adress" angegeben? Das ist in der Regel doch Point2Point Verbindungen. Dort müsste doch die 213er IP stehen...eigentlich ?!"
"GRE Tunnel MT: Warum hast du da keine "Local Adress" angegeben? Das ist in der Regel doch Point2Point Verbindungen. Dort müsste doch die 213er IP stehen...eigentlich ?!"
Habe ich nocht nachträglich eingetragen funktioniert mit oder ohne. Ist warscheinlich erst relevant wenn der Router mehrere WAN Adressen besitzt das die ausgangsadresse immer gleich bleibt.
Zitat von @aqui:
"IPsec Policy: Die beiden Adressen 213... und 176... sind die jeweiligen WAN Ports, richtig ? Warum hast du da "all(255)" als Protokoll drin ? Macht es nicht Sinn das auf 47 zu setzen. GRE ist IP Prot. Nummer 47 Alles andere soll ja NICHT in den IPsec Tunnel"
"IPsec Policy: Die beiden Adressen 213... und 176... sind die jeweiligen WAN Ports, richtig ? Warum hast du da "all(255)" als Protokoll drin ? Macht es nicht Sinn das auf 47 zu setzen. GRE ist IP Prot. Nummer 47 Alles andere soll ja NICHT in den IPsec Tunnel"
Das habe ich auch schon mit 47 getestet dann kommt in Phase 2 keine verbindung zu stande.
Zitat von @aqui:
"Hast du die IPsec Policies und Peers manuell eingerichtet ?? Oder hast du das automatisiert machen lassen durch Definition des "IPsec Secret" Passwords in der GRE Interface Konfig ?"
"Hast du die IPsec Policies und Peers manuell eingerichtet ?? Oder hast du das automatisiert machen lassen durch Definition des "IPsec Secret" Passwords in der GRE Interface Konfig ?"
Ja die IPsec Policies und Peers habe ich manuell eingerichtet, da es mit der PFSens konfiguration nicht hingehauen hat.
Zitat von @aqui:
"Wenn du das IPsec Widget im Dashboard der pfSense installierst kannst du den VPN Tunnel dort im Status "UP" sehen ?"
"Wenn du das IPsec Widget im Dashboard der pfSense installierst kannst du den VPN Tunnel dort im Status "UP" sehen ?"
Ja das funktioniert auch!
Gruß Wienni
Hast du dazu schon erfahrung? vieleicht könntest du mir da auch weiter helfen!
Ja, klar, gerne !Ich habe das in einem reinen MT Setup mit IPsec und GRE hier fehlerlos am Laufen.
Das ist ein (erstmal) simples Setup ohne Ärea Struktur. Alles ist der Einfachheit halber in der Backbone Default Ärea 0.
Interfaces und OSPF Netze:
ether1 = WAN Port mit NAT ins "Internet" Testnetz
172.32.32.0/30 = GRE Tunnel
Rest = Lokale LANs und VLANs
OSPF Interfaces:
Werden automatisch gesetzt wenn du die Netze einträgst.
Hier auf Passiv gesetzt damit akzeptiere ich keine weiteren OSPF Router Updates aus den lokalen LANs
Muss jetzt erstmal das IPsec VPN der pfSense zum Fliegen bringen auf den MT
OSPF Neighbor auf der anderen Seite des Tunnels:
MT RB750
Routing Tabelle:
Die Routen mit der Distance "110" sind gelernte über den GRE Tunnel.
Bei der pfSense hat man 2 Optionen. Einmal Quagga und einmal FRR wenn man OSPF machen will.
FRR kann noch BGP. Wenn man rein nur OSPF macht wäre sicher Quagga sinnvoller, da weniger Overhead. Siehe auch Link oben.
So, habe das IPsec VPN und den GRE Tunnel nun auch zum Laufen hier.
Mein Labor Setup sieht so aus:
Die zur pfSense zusätzliche MT Verbindung habe ich als Kontrolle.
Es gibt aber noch ein paar Probleme. Ggf. kannst du dazu ja nochmal ein Feedback geben mit deinen Settings ?!
Ich bekomme derzeit keinen Traffic vom LAN der pfSense in den GRE Tunnel
Der Fehler muss auf Seiten der pfSense liegen, denn vom lokalen LAN am MT-1 kann ich fehlerfrei das GRE Interface auf der pfSense (172.32.32.6) pingen.
Nicht aber andersrum, sprich vom LAN an der pfSense das GRE Interface des MT-1 (172.32.32.5).
Die GRE Interfaces direkt kann man sowohl von der pfSense als auch vom MT über deren interne Ping Funktion pingen.
Generell funktioniert damit der Tunnel an sich.
Es sieht so aus als ob die pfSense trotz statischer Route des 192.168.88er Netzes dieses nicht in den Tunnel routet.
Frage: Kannst du die lokalen Netze via GRE routen ??
Ich muss dazu sagen das ich derzeit KEINE Regeln auf der pfSense angelegt habe. Weder für das IPsec Interface noch für das GRE Interface. Der IPsec GRE Tunnel funktionierte komischerweise auch so ohne Regeln. Jedenfalls soweit wie oben beschrieben.
Ich hatte daraufhin jeweils auf dem IPsec und GRE Interface dann ANY zu ANY Regeln gesetzt und auch diese Floating Regel wie oben beschrieben.
Keine Änderung.
Kein Routing des lokalen LANs auf pfSense Seite in den Tunnel. Ping geht weiterhin nur direkt
Die spezielle NAT Anpassung habe ich nicht gemacht. Hast du das umgesetzt ?
Hier wäre mal ein Feedback (Screenshot) interessant wie du das gemacht hast sofern du denn lokalen LAN Traffic durch den Tunnel geroutet bekommst auf der pfSense.
Ich will das erstmal sauber mit statischen Routen hinbekommen das das fehlerfrei rennt. Ansonsten muss man mit dynamischen Protokollen erstmal gar nicht probieren.
Im Moment hab ich keine Idee warum die pfSense nichts in den Tunnel routet ??
Riecht irgendwo noch nach Firewall Regel, aber wo ???
Thema IPsec Policy nur mit GRE (Protokoll 47) von oben...
Das liegt aber daran das es dann zu einem Policy Mismatch im IPsec kommt.
Die Lösung ist aber sehr einfach !
Du definierst einfach eine IPsec Firewall Regel PASS Source: ANY IPv4 GRE Destination: ANY
Dann stimmen die Policies wieder und die IPsec Verbindung kommt sofort wieder hoch !
Am Routing Problem hier auf pfSense Seite änderte das aber leider nichts
Mein Labor Setup sieht so aus:
Die zur pfSense zusätzliche MT Verbindung habe ich als Kontrolle.
Es gibt aber noch ein paar Probleme. Ggf. kannst du dazu ja nochmal ein Feedback geben mit deinen Settings ?!
Ich bekomme derzeit keinen Traffic vom LAN der pfSense in den GRE Tunnel
Der Fehler muss auf Seiten der pfSense liegen, denn vom lokalen LAN am MT-1 kann ich fehlerfrei das GRE Interface auf der pfSense (172.32.32.6) pingen.
Nicht aber andersrum, sprich vom LAN an der pfSense das GRE Interface des MT-1 (172.32.32.5).
Die GRE Interfaces direkt kann man sowohl von der pfSense als auch vom MT über deren interne Ping Funktion pingen.
Generell funktioniert damit der Tunnel an sich.
Es sieht so aus als ob die pfSense trotz statischer Route des 192.168.88er Netzes dieses nicht in den Tunnel routet.
Frage: Kannst du die lokalen Netze via GRE routen ??
Ich muss dazu sagen das ich derzeit KEINE Regeln auf der pfSense angelegt habe. Weder für das IPsec Interface noch für das GRE Interface. Der IPsec GRE Tunnel funktionierte komischerweise auch so ohne Regeln. Jedenfalls soweit wie oben beschrieben.
Ich hatte daraufhin jeweils auf dem IPsec und GRE Interface dann ANY zu ANY Regeln gesetzt und auch diese Floating Regel wie oben beschrieben.
Keine Änderung.
Kein Routing des lokalen LANs auf pfSense Seite in den Tunnel. Ping geht weiterhin nur direkt
Die spezielle NAT Anpassung habe ich nicht gemacht. Hast du das umgesetzt ?
Hier wäre mal ein Feedback (Screenshot) interessant wie du das gemacht hast sofern du denn lokalen LAN Traffic durch den Tunnel geroutet bekommst auf der pfSense.
Ich will das erstmal sauber mit statischen Routen hinbekommen das das fehlerfrei rennt. Ansonsten muss man mit dynamischen Protokollen erstmal gar nicht probieren.
Riecht irgendwo noch nach Firewall Regel, aber wo ???
Thema IPsec Policy nur mit GRE (Protokoll 47) von oben...
Das habe ich auch schon mit 47 getestet dann kommt in Phase 2 keine verbindung zu stande.
Das passierte bei mir auch !Das liegt aber daran das es dann zu einem Policy Mismatch im IPsec kommt.
Die Lösung ist aber sehr einfach !
Du definierst einfach eine IPsec Firewall Regel PASS Source: ANY IPv4 GRE Destination: ANY
Dann stimmen die Policies wieder und die IPsec Verbindung kommt sofort wieder hoch !
So, nochmal ausgiebig geforscht....
Also den IPsec Tunnel bekommt man stabil hin sowohl mit IKE1 als auch mit IKE2. Egal ob man die FW den MT oder beide rebootet der IPsec Tunnel kommt sofort stabil wieder hoch.
Nicht so der GRE Tunnel, leider...
Mal kommt der hoch, mal nicht, mal erst nach 30 Minuten oder einer Stunde.
Die pfSense zeigt es im Interface Status leider immer auf "UP" was irreführend ist. Relevant ist z.B. im MT unter "IP Interfaces" der Status. Ist das Interface hier kursiv ist es NICHT aktiv. Ebenso in der Routing Tabelle (IP -> Routes), dort wird es blau wenn es inaktiv ist.
Ich habe bis dato keinen Grund für das Warum gefunden
Egal ob man die Floating Rule auf dem GRE konfiguriert oder eine ANY ANY es bleibt instabil. Sollte der GRE mal etabliert sein ist er nach einem Reboot der FW oder des MT wieder weg. Baut sich also nicht stabil wieder auf.
Interessant auch der Traffic Flow:
Es kommen keinerlei Pakete aus Richtung pfSense zum MT via Tunnel. Andersrum schon...
Auch das Ping Verhalten (sofern der GRE Tunnel aktiv ist) mit dem Ping Tool jeweils im MT und pfSense im GRE lässt auf Probleme der pfSense schliessen:
Warum die pfSense allerdings Pakete aus ihrem lokalen LAN nicht in den GRE Tunnel routet bleibt ein Rätsel.
Übrigens....
Aktiviert man OSPF auf der pfSense (egal ob Quagga oder FRR) sehen sich beide OSPF Neighbors via GRE Tunnel aber es werden keinerlei Routen ausgetauscht.
Hätte mich auch gewundert wenn es mit statischen Routen schon scheitert, scheitert auch ein dynamisches Protokoll.
Sehr spannend wäre also mal die Frage wie sich der GRE Tunnel in deinem Setup verhält ???
Verwendete Firmware Versionen sind hier übrigens:
Also den IPsec Tunnel bekommt man stabil hin sowohl mit IKE1 als auch mit IKE2. Egal ob man die FW den MT oder beide rebootet der IPsec Tunnel kommt sofort stabil wieder hoch.
Nicht so der GRE Tunnel, leider...
Mal kommt der hoch, mal nicht, mal erst nach 30 Minuten oder einer Stunde.
Die pfSense zeigt es im Interface Status leider immer auf "UP" was irreführend ist. Relevant ist z.B. im MT unter "IP Interfaces" der Status. Ist das Interface hier kursiv ist es NICHT aktiv. Ebenso in der Routing Tabelle (IP -> Routes), dort wird es blau wenn es inaktiv ist.
Ich habe bis dato keinen Grund für das Warum gefunden
Egal ob man die Floating Rule auf dem GRE konfiguriert oder eine ANY ANY es bleibt instabil. Sollte der GRE mal etabliert sein ist er nach einem Reboot der FW oder des MT wieder weg. Baut sich also nicht stabil wieder auf.
Interessant auch der Traffic Flow:
Auch das Ping Verhalten (sofern der GRE Tunnel aktiv ist) mit dem Ping Tool jeweils im MT und pfSense im GRE lässt auf Probleme der pfSense schliessen:
- Ping vom Mikrotik Ping Tool auf die pfSense GRE IP = Funktioniert !
- Ping vom Test PC im Mikrotik lokalem LAN auf die pfSense GRE IP = Funktioniert !
- Ping vom pfSense Ping Tool auf die Mikrotik GRE IP = Funktioniert !
- Ping vom Test PC im pfSense lokalem LAN auf die Mikrotik GRE IP = Funktioniert NICHT !
Warum die pfSense allerdings Pakete aus ihrem lokalen LAN nicht in den GRE Tunnel routet bleibt ein Rätsel.
Übrigens....
Aktiviert man OSPF auf der pfSense (egal ob Quagga oder FRR) sehen sich beide OSPF Neighbors via GRE Tunnel aber es werden keinerlei Routen ausgetauscht.
Hätte mich auch gewundert wenn es mit statischen Routen schon scheitert, scheitert auch ein dynamisches Protokoll.
Sehr spannend wäre also mal die Frage wie sich der GRE Tunnel in deinem Setup verhält ???
- Ist der bei dir nach einem Reboot egal welcher Seite stabil ?
- Kannst du aus den jeweiligen LAN Segmenten beide gegenüberliegenden GRE IP Interfaces pingen ?
- Wenn ja, können sich Endgeräte in deinen jeweiligen lokalen LANs gegenseitig pingen ?
Verwendete Firmware Versionen sind hier übrigens:
- pfSense = 2.4.4_p1
- Mikrotik = 6.43.7
Ich bin mir ja nicht sicher ob du das gleiche problem jetzt hast wie ich am anfang?
Bei mir war es allerdings Anderestrumm das ich keinen Traffic von MT zur PFSense bekommen habe.
Wohl das Pingen immer ging, da ich das für alle Netze auf beiden seiten freigeben habe.
Aber was mir geholfen hatte, war der Firewall eintrag in der PFSense mit den TCP Flags einstellung.
Hier auch noch die Nat konfiguration
Bei mir war es allerdings Anderestrumm das ich keinen Traffic von MT zur PFSense bekommen habe.
Wohl das Pingen immer ging, da ich das für alle Netze auf beiden seiten freigeben habe.
Aber was mir geholfen hatte, war der Firewall eintrag in der PFSense mit den TCP Flags einstellung.
Hier auch noch die Nat konfiguration
Danke für dein Feedback !
Die habe ich so eingerichtet, das hat gar nichts gebracht. Auch nicht als ich die Any Any Regel im GRE Interface dann entfernt hatte und die FW rebootet hatte zur Sicherheit.
Hast du sonst noch einen zusätzliche statische FW Regel auf dem GRE (OPT1) Interface oder rein nur diese Floating Regel ??
Was am auffälligsten ist, ist das der GRE Tunnel nicht richtig hochkommt. Das sieht man immer am kursiven Eintrag des Tunnel Interfaces in der MT IP Adressliste.
Mal kommt das erst dann hoch wenn man im pfSense IPsec Status Disconnected und wieder connected, mal aber nicht.
Mal kommt es nach ca. 20 Minuten Wartezeit hoch, mal aber erst nach mehreren Stunden über Nacht.
Ich habe auch mal das pfSense Gateway Monitoring aktiviert auf dem GRE Interface zum MT aber auch das bringt nicht wirklich was.
Wie gesagt die IPsec Verbindung ist absolut stabil und kommt immer hoch egal was passiert. Nur der GRE Tunnel
Ist der bei dir stabil so das er immer hochkommt nach Reboot, Kabel ziehen usw. ?
Es kann dann fast nur noch an den pfSense NAT Einstellungen liegen. Das ist der einzige Punkt an dem ich noch nicht rumgefummelt habe, da ja sonst alles soweit lief. Das ist hier noch alles im Default.
Das nehme ich jetzt nochmal in Angriff und werde berichten....
Ich bin mir ja nicht sicher ob du das gleiche problem jetzt hast wie ich am anfang?
Das will ich nicht ausschliessen und könnte gut sein !Aber was mir geholfen hatte, war der Firewall eintrag in der PFSense mit den TCP Flags einstellung.
Mmmhhh... Du meinst damit diesen "Firewall" Eintrag die Floating Regel für das OPT1 (GRE) Interface, richtig ??Die habe ich so eingerichtet, das hat gar nichts gebracht. Auch nicht als ich die Any Any Regel im GRE Interface dann entfernt hatte und die FW rebootet hatte zur Sicherheit.
Hast du sonst noch einen zusätzliche statische FW Regel auf dem GRE (OPT1) Interface oder rein nur diese Floating Regel ??
Was am auffälligsten ist, ist das der GRE Tunnel nicht richtig hochkommt. Das sieht man immer am kursiven Eintrag des Tunnel Interfaces in der MT IP Adressliste.
Mal kommt das erst dann hoch wenn man im pfSense IPsec Status Disconnected und wieder connected, mal aber nicht.
Mal kommt es nach ca. 20 Minuten Wartezeit hoch, mal aber erst nach mehreren Stunden über Nacht.
Ich habe auch mal das pfSense Gateway Monitoring aktiviert auf dem GRE Interface zum MT aber auch das bringt nicht wirklich was.
Wie gesagt die IPsec Verbindung ist absolut stabil und kommt immer hoch egal was passiert. Nur der GRE Tunnel
Ist der bei dir stabil so das er immer hochkommt nach Reboot, Kabel ziehen usw. ?
Es kann dann fast nur noch an den pfSense NAT Einstellungen liegen. Das ist der einzige Punkt an dem ich noch nicht rumgefummelt habe, da ja sonst alles soweit lief. Das ist hier noch alles im Default.
Das nehme ich jetzt nochmal in Angriff und werde berichten....
So, leider nur ein kleiner temporärer Teilerfolg.
MT hatte ich so gelassen wie er war. GRE und IPsec mit folgenden Settings:
GRE Interface:
MT erzeugt die IPsec Peers dann selber.
IPsec Phase 1 und 2:
Ein Vergleichsetup mit einem anderen MT testweise mit der pfSense IP lief fehlerlos. So konnte ich sicher sein keinen Konfig Fehler im MT zu haben.
GRE Tunnel und Rules gemäß den Infos von oben in der pfSense neu aufgesetzt und damit kam dann auch erstmal alles hoch und funktionierte wie erwartet:
MT Ping auf pfSense LAN klappte auch was ja auch schon vorher lief.
Verhaltene Freude. Soweit so gut...
Da ich aber schon misstrauisch war das alles nach einem Reboot der Komponenten wie hochkam habe ich mit laufendem Ping (-t) von Clients im jeweiligen lokalen LAN auf die gegenüberliegenden LAN Interfaces den MT rebootet um zu testen das wirklich alles wasserdicht ist.
Der MT kam hoch, IPsec sofort wieder "established" aber GRE Tunnel mal wieder nicht obwohl er vorher lief.
Interface Bezeichnung im MT kursiv und Routen auf blau was im MT zeigt das das Tunnelinterface down ist.
Trotz Neustart des IPsec VPNs entweder auf pfSense Seite noch MT (Flush) kommt der GRE Tunnel nicht hoch.
Darauf mal den Wireshark angeworfen um mal zu sehen was auf der WAN Verbindung eigentlich los ist.
Traces zeigen das der IPsec Tunnel sauber zum Laufen kommt (ISAKMP Handshaking). OK, sieht man ja auch auf beiden Seiten am IPsec Status das da alles OK ist.
Dann kommts aber...:
Zum Ersten gehen die GRE Keepalives OHNE IPsec über den WAN Link !:
und zum Zweiten ebenfalls die Gateway Keepalive Pings der pfSense !:
Das dürfte niemals so sein, denn die GRE Pakete müssten sich innerhalb des IPsec Transport Tunnels befinden.
Man dürfte hier also niemals GRE geschweige denn ICMP Pakete sehen, die ja auch noch innerhalb des GRE Tunnels sein müssten !
Es dürften rein nur ESP Pakete sein, niemals aber die GRE und ICMP Pakete im Klartext !!!
Glücklicherweise rennt ja parallel auf 10.99.1.199 noch der laufende MT IPsec GRE Tunnel zum Vergleich und der ist komplett im ESP wie es sich gehört.
Hier läuft also gehörig was schief auf der pfSense !
Mit anderen Worten:
Die pfSense sendet die GRE Pakete NICHT in den IPsec Tunnel !!!
Da ist es dann auch vollkommen klar das der GRE Tunnel nicht zustande kommt. Kein Wunder also...
Fragt sich nur: WORAN liegt das und warum funktioniert es nur einmal nach dem neuen Setup ???
Erste Befürchtung das mit den IPsec Policy Rules was nicht stimmt, also was mit ESP Transport encrypted wird und was nicht. Ich habe daraufhin mal die Firewall Regeln auf dem IPsec Interface angepasst:
Nochmal Frage an dich:
Einziger Unterschied ist jetzt nur noch das du die IPsec Peers auf dem MT manuell eingerichtet hast und ich das automatisiert über das Anlegen der GRE Interfaces (IPsec Secret).
Aber das kanns doch nicht sein, das ist doch nur Konfig Kosmetik...?! Oder etwa doch...?
MT hatte ich so gelassen wie er war. GRE und IPsec mit folgenden Settings:
GRE Interface:
IPsec Phase 1 und 2:
GRE Tunnel und Rules gemäß den Infos von oben in der pfSense neu aufgesetzt und damit kam dann auch erstmal alles hoch und funktionierte wie erwartet:
MT Ping auf pfSense LAN klappte auch was ja auch schon vorher lief.
Verhaltene Freude. Soweit so gut...
Da ich aber schon misstrauisch war das alles nach einem Reboot der Komponenten wie hochkam habe ich mit laufendem Ping (-t) von Clients im jeweiligen lokalen LAN auf die gegenüberliegenden LAN Interfaces den MT rebootet um zu testen das wirklich alles wasserdicht ist.
Der MT kam hoch, IPsec sofort wieder "established" aber GRE Tunnel mal wieder nicht obwohl er vorher lief.
Interface Bezeichnung im MT kursiv und Routen auf blau was im MT zeigt das das Tunnelinterface down ist.
Trotz Neustart des IPsec VPNs entweder auf pfSense Seite noch MT (Flush) kommt der GRE Tunnel nicht hoch.
Darauf mal den Wireshark angeworfen um mal zu sehen was auf der WAN Verbindung eigentlich los ist.
Traces zeigen das der IPsec Tunnel sauber zum Laufen kommt (ISAKMP Handshaking). OK, sieht man ja auch auf beiden Seiten am IPsec Status das da alles OK ist.
Dann kommts aber...:
Zum Ersten gehen die GRE Keepalives OHNE IPsec über den WAN Link !:
Das dürfte niemals so sein, denn die GRE Pakete müssten sich innerhalb des IPsec Transport Tunnels befinden.
Man dürfte hier also niemals GRE geschweige denn ICMP Pakete sehen, die ja auch noch innerhalb des GRE Tunnels sein müssten !
Es dürften rein nur ESP Pakete sein, niemals aber die GRE und ICMP Pakete im Klartext !!!
Glücklicherweise rennt ja parallel auf 10.99.1.199 noch der laufende MT IPsec GRE Tunnel zum Vergleich und der ist komplett im ESP wie es sich gehört.
Hier läuft also gehörig was schief auf der pfSense !
Mit anderen Worten:
Die pfSense sendet die GRE Pakete NICHT in den IPsec Tunnel !!!
Da ist es dann auch vollkommen klar das der GRE Tunnel nicht zustande kommt. Kein Wunder also...
Fragt sich nur: WORAN liegt das und warum funktioniert es nur einmal nach dem neuen Setup ???
Erste Befürchtung das mit den IPsec Policy Rules was nicht stimmt, also was mit ESP Transport encrypted wird und was nicht. Ich habe daraufhin mal die Firewall Regeln auf dem IPsec Interface angepasst:
- GRE any any = keine Wirkung
- OPT1 net to OPT1 net = keine Wirkung
- IPv4 any any = keine Wirkung
Nochmal Frage an dich:
- Hast du im lfd. Betrieb die pfSense mal rebootet ? Wenn ja kommt alles wieder hoch ?
- Dto. mit dem MT ?
- Welche pfSense FW nutzt du ? Heute auf die neue 2.4.4_p2 upgedatet = keine Besserung
- Hast du eine zusätzliche Regel auf dem GRE (OPT1) Interface oder nur rein die Floating Regel ?
- Die zusätzlichen IP Netze der pfSense NAT Regel sind weitere lokale LANs an deiner pfSense, richtig ?
Einziger Unterschied ist jetzt nur noch das du die IPsec Peers auf dem MT manuell eingerichtet hast und ich das automatisiert über das Anlegen der GRE Interfaces (IPsec Secret).
Aber das kanns doch nicht sein, das ist doch nur Konfig Kosmetik...?! Oder etwa doch...?
Hi,
langsam wird es unübersichtlich
Also ich habe es nochmals versucht mit den IPSec einstellungen im GRE Interface. Bekomme dann leider keine verbindung zu stande.
Da die IPSec Police immer das Protocol GRE(47) einstellt und mit diesem klapt es leider nicht, habe es mehrfach versucht und mehrfach die Pass einträge bei Wan und bei IPSec Schnittstelle gesetzt.
Dazu noch eine frage zu deinem Problem:
Ist es nicht richtig, das die ICMP Pakete nicht verschlüsselt werden da die IPSec einstellungen mit dem Protocol 47 nur die GRE Pakete verschlüsselt und alles andere unberührt lässt?
Was mir noch aufgefallen ist, ich habe keine Keepalive einstellungen im GRE Interface auf MT seite gesetzt.
Ich habe dir mal ein screenshot von den PSSense ->System ->Advanced -> Firewall & NAT einstellungen gemacht.
An den roten makierungen hatte ich mal rumgespielt vieleicht hilft das noch weiter.
Ich habe nur eine PASS ANY ANY Regel auf OPT1
Weiterhin viel erfolg.
langsam wird es unübersichtlich
Zitat von @aqui:
So, leider nur ein kleiner temporärer Teilerfolg.
MT hatte ich so gelassen wie er war. GRE und IPsec mit folgenden Settings:
GRE Interface:
So, leider nur ein kleiner temporärer Teilerfolg.
MT hatte ich so gelassen wie er war. GRE und IPsec mit folgenden Settings:
GRE Interface:
Also ich habe es nochmals versucht mit den IPSec einstellungen im GRE Interface. Bekomme dann leider keine verbindung zu stande.
Da die IPSec Police immer das Protocol GRE(47) einstellt und mit diesem klapt es leider nicht, habe es mehrfach versucht und mehrfach die Pass einträge bei Wan und bei IPSec Schnittstelle gesetzt.
Dazu noch eine frage zu deinem Problem:
Darauf mal den Wireshark angeworfen um mal zu sehen was auf der WAN Verbindung eigentlich los ist.
Traces zeigen das der IPsec Tunnel sauber zum Laufen kommt (ISAKMP Handshaking). OK, sieht man ja auch auf beiden Seiten am IPsec Status das da alles OK ist.
Dann kommts aber...:
Zum Ersten gehen die GRE Keepalives OHNE IPsec über den WAN Link !:
und zum Zweiten ebenfalls die Gateway Keepalive Pings der pfSense !:
Das dürfte niemals so sein, denn die GRE Pakete müssten sich innerhalb des IPsec Transport Tunnels befinden.
Man dürfte hier also niemals GRE geschweige denn ICMP Pakete sehen, die ja auch noch innerhalb des GRE Tunnels sein müssten !
Es dürften rein nur ESP Pakete sein, niemals aber die GRE und ICMP Pakete im Klartext !!!
Glücklicherweise rennt ja parallel auf 10.99.1.199 noch der laufende MT IPsec GRE Tunnel zum Vergleich und der ist komplett im ESP wie es sich gehört.
Hier läuft also gehörig was schief auf der pfSense !
Traces zeigen das der IPsec Tunnel sauber zum Laufen kommt (ISAKMP Handshaking). OK, sieht man ja auch auf beiden Seiten am IPsec Status das da alles OK ist.
Dann kommts aber...:
Zum Ersten gehen die GRE Keepalives OHNE IPsec über den WAN Link !:
Das dürfte niemals so sein, denn die GRE Pakete müssten sich innerhalb des IPsec Transport Tunnels befinden.
Man dürfte hier also niemals GRE geschweige denn ICMP Pakete sehen, die ja auch noch innerhalb des GRE Tunnels sein müssten !
Es dürften rein nur ESP Pakete sein, niemals aber die GRE und ICMP Pakete im Klartext !!!
Glücklicherweise rennt ja parallel auf 10.99.1.199 noch der laufende MT IPsec GRE Tunnel zum Vergleich und der ist komplett im ESP wie es sich gehört.
Hier läuft also gehörig was schief auf der pfSense !
Ist es nicht richtig, das die ICMP Pakete nicht verschlüsselt werden da die IPSec einstellungen mit dem Protocol 47 nur die GRE Pakete verschlüsselt und alles andere unberührt lässt?
Was mir noch aufgefallen ist, ich habe keine Keepalive einstellungen im GRE Interface auf MT seite gesetzt.
Ich habe dir mal ein screenshot von den PSSense ->System ->Advanced -> Firewall & NAT einstellungen gemacht.
An den roten makierungen hatte ich mal rumgespielt vieleicht hilft das noch weiter.
- Hast du im lfd. Betrieb die pfSense mal rebootet ? Wenn ja kommt alles wieder hoch ?
Habe ich bislang nicht gemacht, aber die IPSec und GRE Tunnel tennen lassen. - Dto. mit dem MT ?
Nach einem neustart ist der IPSec/GRE Tunner nach etwa einer Minute wieder aufgebaut.- Welche pfSense FW nutzt du ? Heute auf die neue 2.4.4_p2 upgedatet = keine Besserung
2.4.4-RELEASE-p1 (amd64)- Hast du eine zusätzliche Regel auf dem GRE (OPT1) Interface oder nur rein die Floating Regel ?
Ich habe nur eine PASS ANY ANY Regel auf OPT1
- Die zusätzlichen IP Netze der pfSense NAT Regel sind weitere lokale LANs an deiner pfSense, richtig ?
Sowohl ein Lokales Netz auf der PFSense seite und verschiedene lokale netze auf der MT seite.Weiterhin viel erfolg.
Hi wienni,
Wie gesagt, wenn ich die pfSense IPsec PASS Regel auf GRE any any setze kommt die IPsec Verbindung sofort wieder hoch.
Aber egal, ich habe es jetzt genau so wie du gemacht und die IPsec Peers im Transport Mode manuell konfiguriert und dann das Protokoll auf "all(255)" belassen. IPsec Rule pfSense dann auch auf PASS any any angepasst.
Im ersten Step brachte das keine Verbersserung aber aus lauter Frust habe ich dann den NAT Outbound Mode mal testweise wieder auf Automatic gesetzt was wie erwartet auch keinen Effekt hatte.
Daraufhin habe ich ihn wieder auf Manuell (AON) zurückgesetzt und plötzlich waren auch die statischen Routen mit Regel übernommen. Also erheblich mehr als da vorher drinstand.
Neugierig hab ich dann mal einen Ping gemacht im pfSense Ping Tool auf die MT GRE Tunneladresse und siehe da das klappte. Vice Versa auch vom MT auf den pfSense Tunnel.
Ping der LAN IPs klappte aber nicht...
Daraufhin habe ich den WAN Port gesniffert und die nicht ESP enkapsulierten Frames waren dann wie von Geisterhand verschwunden.
Bug or Feature ??
Alles was über das GRE Interface (hier 172.32.32.4 /30er Netz) rennt kommt ja in den GRE Tunnel und wird an deine gegenüberliegende WAN IP gesendet.
Alles was zwischen pfSense und MT über deren WAN IPs ausgetauscht wird landet in einem IPsec ESP Paket. Das ist deine Protocoll = all(255) Regel Damit natürlich auch aller GRE Traffic. Das Gateway Monitoring nutzt ja einen 172.32.32.5er Absender IP also GRE und sollte damit im Tunnel landen als ESP Packet.
Generell sollte man mit Protocoll = all(255) gar nichts mehr im Klartext sehen zwischen den beiden WAN IPs der pfSense und des MT, denn das ist ja dann alles ESP Transport verschlüsselt. Sagt auch die SA Policies die ja beide WAN IPs beinhalten.
Deshalb würde es Sinn machen nur den GRE Traffic zu verschlüsseln. Wie gesagt bei mir klappt das, aber das ist jetzt erstmal ein kosmetisches Problem.
Es ist möglich das auf der pfSense noch eine statische Route fehlt das das 172.32.32.6er Interface via WAN Port geroutet werden muss ? Das wäre nochmal einen Test wert !
Hier ist übrigens noch ein Video. Zwar mit alter GUI zeigt aber auch die Schritte:
https://www.youtube.com/watch?v=YPYFcya3Qls
Letztlich alles was wir auch schon gemacht haben.
Was ich mich frage ist ob man wirklich noch eine statische Rule auf dem GRE Interface benötigt ?! In keiner Anleitung wird das erwähnt. Ist ja auch nicht weiter verwunderlich, den die "Floating Rule" ist ja auf das GRE Interface (bei uns OPT1) eingerichtet. Wozu also zu einer Floating Rule noch eine Statische ?
Ich hatte auch beides drin und auch nur die Floating Rule aber das hatte keinerlei Auswirkungen auf die Funktion.
Die GRE Keepalives sind übrigens ganz sinnvoll. Zum einen triggern sie immer den IPsec Link und sorgen dafür das der always up ist. Zum Zweiten sorgen sie auch dafür das das GRE Interface auf Down geht sollten diese Updates ausbleiben.
Das war aber noch ein guter Tip das das bei dir auf AUS ist.
Sehr gut möglich das die pfSesne gar keine GRE Keepalives supportet (ich habe im Setup nix gesehen !), der MT aber erwartet das welche kommen (Ich habe die aktiv). Logisch das der MT dann immer das Interface auf Down hat.
Ein neuer Forschungsansatz !!! Das teste ich aus !
Parallel habe ich mal einen Cisco Router angeschmissen und konfiguriere von dem auch mal einen IPsec Transport GRE Tunnel auf den MT.
Mal sehen was der so sagt....?!
Es bleibt also spannend !
Wie gesagt, wenn ich die pfSense IPsec PASS Regel auf GRE any any setze kommt die IPsec Verbindung sofort wieder hoch.
Aber egal, ich habe es jetzt genau so wie du gemacht und die IPsec Peers im Transport Mode manuell konfiguriert und dann das Protokoll auf "all(255)" belassen. IPsec Rule pfSense dann auch auf PASS any any angepasst.
Im ersten Step brachte das keine Verbersserung aber aus lauter Frust habe ich dann den NAT Outbound Mode mal testweise wieder auf Automatic gesetzt was wie erwartet auch keinen Effekt hatte.
Daraufhin habe ich ihn wieder auf Manuell (AON) zurückgesetzt und plötzlich waren auch die statischen Routen mit Regel übernommen. Also erheblich mehr als da vorher drinstand.
Neugierig hab ich dann mal einen Ping gemacht im pfSense Ping Tool auf die MT GRE Tunneladresse und siehe da das klappte. Vice Versa auch vom MT auf den pfSense Tunnel.
Ping der LAN IPs klappte aber nicht...
Daraufhin habe ich den WAN Port gesniffert und die nicht ESP enkapsulierten Frames waren dann wie von Geisterhand verschwunden.
Bug or Feature ??
Ist es nicht richtig, das die ICMP Pakete nicht verschlüsselt werden da die IPSec einstellungen mit dem Protocol 47 nur die GRE Pakete verschlüsselt und alles andere unberührt lässt?
Nein, sollte eigentlich nicht.Alles was über das GRE Interface (hier 172.32.32.4 /30er Netz) rennt kommt ja in den GRE Tunnel und wird an deine gegenüberliegende WAN IP gesendet.
Alles was zwischen pfSense und MT über deren WAN IPs ausgetauscht wird landet in einem IPsec ESP Paket. Das ist deine Protocoll = all(255) Regel
Damit natürlich auch aller GRE Traffic. Das Gateway Monitoring nutzt ja einen 172.32.32.5er Absender IP also GRE und sollte damit im Tunnel landen als ESP Packet.Generell sollte man mit Protocoll = all(255) gar nichts mehr im Klartext sehen zwischen den beiden WAN IPs der pfSense und des MT, denn das ist ja dann alles ESP Transport verschlüsselt. Sagt auch die SA Policies die ja beide WAN IPs beinhalten.
Deshalb würde es Sinn machen nur den GRE Traffic zu verschlüsseln. Wie gesagt bei mir klappt das, aber das ist jetzt erstmal ein kosmetisches Problem.
Es ist möglich das auf der pfSense noch eine statische Route fehlt das das 172.32.32.6er Interface via WAN Port geroutet werden muss ? Das wäre nochmal einen Test wert !
Hier ist übrigens noch ein Video. Zwar mit alter GUI zeigt aber auch die Schritte:
https://www.youtube.com/watch?v=YPYFcya3Qls
Letztlich alles was wir auch schon gemacht haben.
Was ich mich frage ist ob man wirklich noch eine statische Rule auf dem GRE Interface benötigt ?! In keiner Anleitung wird das erwähnt. Ist ja auch nicht weiter verwunderlich, den die "Floating Rule" ist ja auf das GRE Interface (bei uns OPT1) eingerichtet. Wozu also zu einer Floating Rule noch eine Statische ?
Ich hatte auch beides drin und auch nur die Floating Rule aber das hatte keinerlei Auswirkungen auf die Funktion.
Die GRE Keepalives sind übrigens ganz sinnvoll. Zum einen triggern sie immer den IPsec Link und sorgen dafür das der always up ist. Zum Zweiten sorgen sie auch dafür das das GRE Interface auf Down geht sollten diese Updates ausbleiben.
Das war aber noch ein guter Tip das das bei dir auf AUS ist.
Sehr gut möglich das die pfSesne gar keine GRE Keepalives supportet (ich habe im Setup nix gesehen !), der MT aber erwartet das welche kommen (Ich habe die aktiv). Logisch das der MT dann immer das Interface auf Down hat.
Ein neuer Forschungsansatz !!! Das teste ich aus !
Parallel habe ich mal einen Cisco Router angeschmissen und konfiguriere von dem auch mal einen IPsec Transport GRE Tunnel auf den MT.
Mal sehen was der so sagt....?!
Es bleibt also spannend !
Die IPsec GRE Saga geht weiter mit etwas Lesestoff zum Wochenende....
Die guten Nachrichten vorweg um mal mit dem Positiven anzufangen.
Die IPsec GRE Kopplung mit dem Cisco funktioniert fehlerlos und sofort auf Anhieb. Auch mehrere Reboot Szenarien und simulierte WAN(Internet) Ausfälle überlebt das ganze Setup fehlerlos wie auch rein die MTs unter sich.
Testdesign ist das gleiche 3 Router Setup wie oben in der Skizze, quasi statt pfSense der Cisco Router.
MT GRE Interface Setup für den Cisco:
MT IPsec Peer Setup für den Cisco:
Cisco Router Konfig:
!
crypto isakmp policy 10
encr aes 256
hash sha256
authentication pre-share
group 14
crypto isakmp key test123 address 10.1.1.150 255.255.255.0 no-xauth
!
crypto ipsec transform-set mikrotik esp-aes 256 esp-sha256-hmac
mode transport
!
crypto map mikrotik 10 ipsec-isakmp
set peer 10.1.1.150
set transform-set mikrotik
set pfs group14
match address 107
!
access-list 107 permit gre host 10.99.1.198 host 10.1.1.150
!
interface FastEthernet3
description Internet / WAN
switchport access vlan 99
no ip address
no cdp enable
!
interface Tunnel0
description GRE Tunnel Mikrotik
ip address 172.31.31.9 255.255.255.252
ip mtu 1400
tunnel source 10.99.1.198
tunnel destination 10.1.1.150
tunnel path-mtu-discovery
!
interface vlan 1
description Lokales LAN (Port FastEth 0)
ip address 192.168.77.1 255.255.255.0
ip nat inside
!
interface vlan 99
description WAN/Internet (Port FastEth 3)
ip address 10.99.1.198
ip nat outside
crypto map mikrotik
!
Damit rennt alles stabil und fehlerlos.
On Top habe ich darauf über die 3 Router (2 mal MT, Cisco 831) jeweils ein OSPF Setup und zum Vergleich statt OSPF ein RIPv2 Setup laufen lassen und alle angeschlossenen Netze dynamisch routen lassen.
Auch das klappte ohne Zicken absolut fehlerfrei und vollkommen unauffällig !!
Beispiel für die RIPv2 Konfig Cisco:
!
router rip
version 2
passive-interface default
no passive-interface Tunnel0
network 172.31.0.0
network 192.168.77.0
no auto-summary
!
Das RIPv2 Pendant auf der Mikrotik Gegenseite:
Routing Tabelle Cisco:
Man sieht hier alle dynamisch mit "R" von den Mikrotiks gelernten RIPv2 Routen via GRE Tunnel Interface.
Cisco - Mikrotik also ein Dreamteam
Kommen wir zum Sorgenkind pfSense....
Setup nochmal überprüft und exakt so konfiguriert wie oben bzw. dem Tutorial.
GRE Keepalives ausgeschaltet auf dem MT.
Zur Sicherheit nochmal beide rebootet, MT und pfSense.
IPsec Verbindung war sofort wieder da auf beiden Seiten und da das Tunnel Interface auf dem MT jetzt nicht mehr kursiv (Down) dargestellt war keimte Hoffnung auf. Aber wenn die Keepalives deaktiviert sind war davon auszugehen das es vermutlich dann statisch auf UP geht. So war es dann auch...
Kein Ping auf dem Tunnel Interface von pfSense zum MT möglich
Ich habe (was selten ist ) langsam keine Idee mehr warum die GRE Tunnel Verbindung nicht oder nur sehr sporadisch zustande kommt. Außer das das wirklich ein Bug in der Firmware ist.
Wie gesagt...spannend wäre mal zu wissen ob deine Konfig einen pfSense Reboot überlebt.
Wenn ja dann bleibt mir wohl nur mal deine pfSense Konfig in meine hier zu spielen und das damit zu testen....
Ansonsten habe ich zum verregneten Wochenende ja noch die Option pfSense zu Cisco mal zu testen
Es bleibt also weiter spannend !!
P.S.: Mit Schrecken habe ich übrigens bemerkt das ist mit den 172.32.32.x GRE Tunnel IPs keine RFC1918 IPs mehr genutzt habe. Wie peinlich... Zwar für die Funktion unerheblich aber ein schlechtes Beispiel hier im Admin Forum.
Also bitte an die Mitleser: NICHT zuhause nachmachen !!!
Ich hab's auch ganz schnell auf 172.31.31.er Netze korrigiert um wieder konform zu sein.
Also nicht wundern über den Unterschied. Das ist natürlich nicht der Grund bei der pfSense, denn die wurden da natürlich auch angepasst !
Die guten Nachrichten vorweg um mal mit dem Positiven anzufangen.
Die IPsec GRE Kopplung mit dem Cisco funktioniert fehlerlos und sofort auf Anhieb. Auch mehrere Reboot Szenarien und simulierte WAN(Internet) Ausfälle überlebt das ganze Setup fehlerlos wie auch rein die MTs unter sich.
Testdesign ist das gleiche 3 Router Setup wie oben in der Skizze, quasi statt pfSense der Cisco Router.
MT GRE Interface Setup für den Cisco:
MT IPsec Peer Setup für den Cisco:
Cisco Router Konfig:
!
crypto isakmp policy 10
encr aes 256
hash sha256
authentication pre-share
group 14
crypto isakmp key test123 address 10.1.1.150 255.255.255.0 no-xauth
!
crypto ipsec transform-set mikrotik esp-aes 256 esp-sha256-hmac
mode transport
!
crypto map mikrotik 10 ipsec-isakmp
set peer 10.1.1.150
set transform-set mikrotik
set pfs group14
match address 107
!
access-list 107 permit gre host 10.99.1.198 host 10.1.1.150
!
interface FastEthernet3
description Internet / WAN
switchport access vlan 99
no ip address
no cdp enable
!
interface Tunnel0
description GRE Tunnel Mikrotik
ip address 172.31.31.9 255.255.255.252
ip mtu 1400
tunnel source 10.99.1.198
tunnel destination 10.1.1.150
tunnel path-mtu-discovery
!
interface vlan 1
description Lokales LAN (Port FastEth 0)
ip address 192.168.77.1 255.255.255.0
ip nat inside
!
interface vlan 99
description WAN/Internet (Port FastEth 3)
ip address 10.99.1.198
ip nat outside
crypto map mikrotik
!
Damit rennt alles stabil und fehlerlos.
On Top habe ich darauf über die 3 Router (2 mal MT, Cisco 831) jeweils ein OSPF Setup und zum Vergleich statt OSPF ein RIPv2 Setup laufen lassen und alle angeschlossenen Netze dynamisch routen lassen.
Auch das klappte ohne Zicken absolut fehlerfrei und vollkommen unauffällig !!
Beispiel für die RIPv2 Konfig Cisco:
!
router rip
version 2
passive-interface default
no passive-interface Tunnel0
network 172.31.0.0
network 192.168.77.0
no auto-summary
!
Das RIPv2 Pendant auf der Mikrotik Gegenseite:
cisco886#sh ip rou
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 10.99.1.254 to network 0.0.0.0
S* 0.0.0.0/0 [254/0] via 10.99.1.254
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.99.1.0/24 is directly connected, Vlan99
L 10.99.1.198/32 is directly connected, Vlan99
172.16.0.0/25 is subnetted, 2 subnets
R 172.16.88.0 [120/1] via 172.31.31.10, 00:00:17, Tunnel0
R 172.16.88.128 [120/1] via 172.31.31.10, 00:00:17, Tunnel0
172.31.0.0/16 is variably subnetted, 3 subnets, 2 masks
R 172.31.31.0/30 [120/1] via 172.31.31.10, 00:00:17, Tunnel0
C 172.31.31.8/30 is directly connected, Tunnel0
L 172.31.31.9/32 is directly connected, Tunnel0
192.168.77.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.77.0/24 is directly connected, Vlan1
L 192.168.77.1/32 is directly connected, Vlan1
R 192.168.88.0/24 [120/1] via 172.31.31.10, 00:00:17, Tunnel0
R 192.168.99.0/24 [120/2] via 172.31.31.10, 00:00:17, Tunnel0
192.168.199.0/25 is subnetted, 1 subnets
R 192.168.199.0 [120/2] via 172.31.31.10, 00:00:17, Tunnel0 Cisco - Mikrotik also ein Dreamteam
Kommen wir zum Sorgenkind pfSense....
Setup nochmal überprüft und exakt so konfiguriert wie oben bzw. dem Tutorial.
GRE Keepalives ausgeschaltet auf dem MT.
Zur Sicherheit nochmal beide rebootet, MT und pfSense.
IPsec Verbindung war sofort wieder da auf beiden Seiten und da das Tunnel Interface auf dem MT jetzt nicht mehr kursiv (Down) dargestellt war keimte Hoffnung auf. Aber wenn die Keepalives deaktiviert sind war davon auszugehen das es vermutlich dann statisch auf UP geht. So war es dann auch...
Kein Ping auf dem Tunnel Interface von pfSense zum MT möglich
Ich habe (was selten ist
) langsam keine Idee mehr warum die GRE Tunnel Verbindung nicht oder nur sehr sporadisch zustande kommt. Außer das das wirklich ein Bug in der Firmware ist.Wie gesagt...spannend wäre mal zu wissen ob deine Konfig einen pfSense Reboot überlebt.
Wenn ja dann bleibt mir wohl nur mal deine pfSense Konfig in meine hier zu spielen und das damit zu testen....
Ansonsten habe ich zum verregneten Wochenende ja noch die Option pfSense zu Cisco mal zu testen
Es bleibt also weiter spannend !!
P.S.: Mit Schrecken habe ich übrigens bemerkt das ist mit den 172.32.32.x GRE Tunnel IPs keine RFC1918 IPs mehr genutzt habe. Wie peinlich... Zwar für die Funktion unerheblich aber ein schlechtes Beispiel hier im Admin Forum.
Also bitte an die Mitleser: NICHT zuhause nachmachen !!!
Ich hab's auch ganz schnell auf 172.31.31.er Netze korrigiert um wieder konform zu sein.
Also nicht wundern über den Unterschied. Das ist natürlich nicht der Grund bei der pfSense, denn die wurden da natürlich auch angepasst !
Update:
Mittlerweile existiert auch ein Tutorial dazu im Internet:
https://aspel.github.io/2018-11-19/ospf-over-gre-tunnel-with-ipsec-mikro ...
Zusätzlich gibt es eine neue IPsec Funktion in der pfSense Firmware 2.4.4 "Routed IPsec" die ein dynamisches Routing ohne GRE Interfaces supportet:
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/ipsec-routed.html
Routed IPsec in pfSense 2.4.4
Mittlerweile existiert auch ein Tutorial dazu im Internet:
https://aspel.github.io/2018-11-19/ospf-over-gre-tunnel-with-ipsec-mikro ...
Zusätzlich gibt es eine neue IPsec Funktion in der pfSense Firmware 2.4.4 "Routed IPsec" die ein dynamisches Routing ohne GRE Interfaces supportet:
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/ipsec-routed.html
Routed IPsec in pfSense 2.4.4
Guuuuten Abend,
kurze Frage mal in die Runde Bin soeben auf diesen Thread gestoßen.
Habe dieses Konstrukt auch gebaut. IPSEC MT zu PFSENSE GRE Tunnel über zwei Provider OSPF etc.
Hab ne aktuelle PFSENSE und auch das Problem mit dem Traffic gehabt. Ping ging der Rest nicht
Und wenn ich auf den GRE Interfaces alle Regeln gelöscht habe, ging trotzdem noch ein Ping. Merkwürdig. Irgendwie geht es jetzt, ich traue dem Braten aber noch nicht so ganz.
Habt ihr / Du Erfahrungen zum Routed IPEC in der PFSENSE?
kurze Frage mal in die Runde
Bin soeben auf diesen Thread gestoßen.Habe dieses Konstrukt auch gebaut. IPSEC MT zu PFSENSE GRE Tunnel über zwei Provider OSPF etc.
Hab ne aktuelle PFSENSE und auch das Problem mit dem Traffic gehabt. Ping ging der Rest nicht
Und wenn ich auf den GRE Interfaces alle Regeln gelöscht habe, ging trotzdem noch ein Ping. Merkwürdig. Irgendwie geht es jetzt, ich traue dem Braten aber noch nicht so ganz.Habt ihr / Du Erfahrungen zum Routed IPEC in der PFSENSE?
Okay... Bug oder Feature
Also über die Floating Rules läuft es und der Traffic geht durch.
Was ich auch berichten / bestätigen kann, nach dem Neustart der Sense kommt der GRE Tunnel scheinbar nicht sauber hoch manchmal. Ein bisschen in den GRE Einstellungen geklickt (PFSENE Seite), IP um eine Stelle verändert und wieder rückgängig gemacht, Apply - Dann steht er
Aber produktiv ist es durch das GRE Problem nicht nutzbar. Auf der Mikrotik Seite kann man den Fehler auch nicht lösen (z.B. Interface disable/enable) sonst hätte man es ja scripten können oder mit Netwatch z.B. Der Fehler scheint aber auf der PFSENSE Seite zu liegen
Also über die Floating Rules läuft es und der Traffic geht durch.
Was ich auch berichten / bestätigen kann, nach dem Neustart der Sense kommt der GRE Tunnel scheinbar nicht sauber hoch manchmal. Ein bisschen in den GRE Einstellungen geklickt (PFSENE Seite), IP um eine Stelle verändert und wieder rückgängig gemacht, Apply - Dann steht er
Aber produktiv ist es durch das GRE Problem nicht nutzbar. Auf der Mikrotik Seite kann man den Fehler auch nicht lösen (z.B. Interface disable/enable) sonst hätte man es ja scripten können oder mit Netwatch z.B. Der Fehler scheint aber auf der PFSENSE Seite zu liegen
Arbeitest du mit einer VTI Konfiguration ??
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Mit VTI gibt es diese Probleme nicht, da rennt es auf der pfSense absolut stabil. GRE Tunnel zu einem Cisco hat über Monate keinen Fehler.
Nachteil ist nur das Mikrotik derzeit (noch) kein VTI supportet. VTI ist die erheblich bessere Option das umzusetzen.
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Mit VTI gibt es diese Probleme nicht, da rennt es auf der pfSense absolut stabil. GRE Tunnel zu einem Cisco hat über Monate keinen Fehler.
Nachteil ist nur das Mikrotik derzeit (noch) kein VTI supportet. VTI ist die erheblich bessere Option das umzusetzen.
Moinsen,
neee aktuell habe ich es so eingerichtet, wie in dem Tutorial:
https://aspel.github.io/2018-11-19/ospf-over-gre-tunnel-with-ipsec-mikro ...
VTI habe ich zwischen zwei Sensen mal getestet. Das ist glaube ich wirklich die bessere Wahl. Bleibt dann abzuwarten, bis MT das unterstützt.
Der GRE Tunnel über IPSEC wie in dem Tutorial steht wirklich stabil, das habe ich auch festgestellt. Gestern kam er nach dem Neustart der Sense aber nicht hoch. Das fand ich etwas merkwürdig.
Ein Trace auf den GRE Interface der Sense brachte allerdings Pakete ans Licht, welche ich auf der anderen Seite (Mikrotik) in den Tunnel geschickt habe. Nur es kam keine Antwort. Ausgehende Pakete auf dem GRE Interface der Sense = 0
neee aktuell habe ich es so eingerichtet, wie in dem Tutorial:
https://aspel.github.io/2018-11-19/ospf-over-gre-tunnel-with-ipsec-mikro ...
VTI habe ich zwischen zwei Sensen mal getestet. Das ist glaube ich wirklich die bessere Wahl. Bleibt dann abzuwarten, bis MT das unterstützt.
Der GRE Tunnel über IPSEC wie in dem Tutorial steht wirklich stabil, das habe ich auch festgestellt. Gestern kam er nach dem Neustart der Sense aber nicht hoch. Das fand ich etwas merkwürdig.
Ein Trace auf den GRE Interface der Sense brachte allerdings Pakete ans Licht, welche ich auf der anderen Seite (Mikrotik) in den Tunnel geschickt habe. Nur es kam keine Antwort. Ausgehende Pakete auf dem GRE Interface der Sense = 0
Nur es kam keine Antwort. Ausgehende Pakete auf dem GRE Interface der
Das kann auch eine Frage der richtigen MTU sein. Das ist bei Szenarion mit doppelter Encapsulation (GRE in IPsec) nicht ganz trivial. Hier musst du aufpassen das die Interface die korrekten MTUs definiert haben.https://baturin.org/tools/encapcalc/
