Top-Themen

Aktuelle Themen (A bis Z)

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

gelöst Zwischen Miktrotik und PFSense GRE Tunnel mit IPSec Verschlüsslung

Mitglied: wienni

wienni (Level 1) - Jetzt verbinden

02.01.2019 um 21:56 Uhr, 341 Aufrufe, 14 Kommentare, 2 Danke

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?


firewall - Klicke auf das Bild, um es zu vergrößern

@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.
Mitglied: aqui
03.01.2019, aktualisiert um 09:39 Uhr
Grundlagen der Mikrotik Konfig für das Design findest du hier:
https://administrator.de/content/detail.php?id=396127&token=466#comm ...

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.
Bitte warten ..
Mitglied: aqui
LÖSUNG 03.01.2019, aktualisiert um 19:22 Uhr
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 ?!
Bitte warten ..
Mitglied: wienni
03.01.2019 um 23:37 Uhr
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-mikro ..."
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
gre-tunnel - Klicke auf das Bild, um es zu vergrößern
ipsec1 - Klicke auf das Bild, um es zu vergrößern
ipsec2 - Klicke auf das Bild, um es zu vergrößern
PFSense
pfsenseipsec - Klicke auf das Bild, um es zu vergrößern
pfsensgrekonf - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: aqui
LÖSUNG 04.01.2019, aktualisiert um 13:14 Uhr
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.

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)
Diese Umstellung bzw. Angleichung muss man machen ohne das würde sonst kein IPsec Tunnel im Main Mode zustande kommen !
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 !
Bitte warten ..
Mitglied: wienni
04.01.2019 um 14:22 Uhr
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:

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 ?!"

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"

Das habe ich auch schon mit 47 getestet dann kommt in Phase 2 keine verbindung zu stande.
ipsec47 - Klicke auf das Bild, um es zu vergrößern

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 ?"

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 ?"

Ja das funktioniert auch!

Gruß Wienni
Bitte warten ..
Mitglied: aqui
04.01.2019, aktualisiert um 15:15 Uhr
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
ospf1 - Klicke auf das Bild, um es zu vergrößern

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
ospf2 - Klicke auf das Bild, um es zu vergrößern

Muss jetzt erstmal das IPsec VPN der pfSense zum Fliegen bringen auf den MT

OSPF Neighbor auf der anderen Seite des Tunnels:
MT RB750
ospf3 - Klicke auf das Bild, um es zu vergrößern

Routing Tabelle:
Die Routen mit der Distance "110" sind gelernte über den GRE Tunnel.
ospf4 - Klicke auf das Bild, um es zu vergrößern

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.
Bitte warten ..
Mitglied: aqui
05.01.2019, aktualisiert um 12:22 Uhr
So, habe das IPsec VPN und den GRE Tunnel nun auch zum Laufen hier.
Mein Labor Setup sieht so aus:

gre-test - Klicke auf das Bild, um es zu vergrößern

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.
grerou1 - Klicke auf das Bild, um es zu vergrößern
grerou2 - Klicke auf das Bild, um es zu vergrößern
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 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 !

gre-pf - Klicke auf das Bild, um es zu vergrößern
Am Routing Problem hier auf pfSense Seite änderte das aber leider nichts
Bitte warten ..
Mitglied: aqui
06.01.2019, aktualisiert um 13:55 Uhr
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:
ipsec1 - Klicke auf das Bild, um es zu vergrößern
ipsec2 - Klicke auf das Bild, um es zu vergrößern
ipsec3 - Klicke auf das Bild, um es zu vergrößern
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:
  • 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 !
Letzteres ist schon komisch, denn der Ping vom Test PC im Mikrotik lokalem LAN auf die pfSense GRE IP sollte dort mit einer 192.168.88.x Absender IP ankommen, was ja dann bedeutet das die pfSense richtig routet.
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 ?
Feedback dazu wäre sehr hilfreich.
Verwendete Firmware Versionen sind hier übrigens:
  • pfSense = 2.4.4_p1
  • Mikrotik = 6.43.7
Bitte warten ..
Mitglied: wienni
06.01.2019, aktualisiert um 19:18 Uhr
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.

firewallopt2 - Klicke auf das Bild, um es zu vergrößern
firewallopt1 - Klicke auf das Bild, um es zu vergrößern

Hier auch noch die Nat konfiguration
nat - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: aqui
07.01.2019 um 11:51 Uhr
Danke für dein Feedback !
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....
Bitte warten ..
Mitglied: aqui
09.01.2019, aktualisiert um 15:40 Uhr
So, leider nur ein kleiner temporärer Teilerfolg.
MT hatte ich so gelassen wie er war. GRE und IPsec mit folgenden Settings:
GRE Interface:
mtgre1 - Klicke auf das Bild, um es zu vergrößern
MT erzeugt die IPsec Peers dann selber.
IPsec Phase 1 und 2:
mtgre2 - Klicke auf das Bild, um es zu vergrößern
mtgre3 - Klicke auf das Bild, um es zu vergrößern
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:
pingpf - Klicke auf das Bild, um es zu vergrößern

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 !:
ws2 - Klicke auf das Bild, um es zu vergrößern
und zum Zweiten ebenfalls die Gateway Keepalive Pings der pfSense !:
ws1 - Klicke auf das Bild, um es zu vergrößern

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
Die Gateway Monitoring Pakets und GRE Hellos der pfSense kommen weiterhin NICHT eingekapselt im IPsec !

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...?
Bitte warten ..
Mitglied: wienni
09.01.2019, aktualisiert um 22:04 Uhr
Hi,

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:
mtgre1 - Klicke auf das Bild, um es zu vergrößern

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 !:
ws2 - Klicke auf das Bild, um es zu vergrößern
und zum Zweiten ebenfalls die Gateway Keepalive Pings der pfSense !:
ws1 - Klicke auf das Bild, um es zu vergrößern

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
firewalldirektopt1 - Klicke auf das Bild, um es zu vergrößern


- 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.
pfsenseadvanced - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: aqui
10.01.2019, aktualisiert 11.01.2019
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 ??
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 !
Bitte warten ..
Mitglied: aqui
11.01.2019, aktualisiert 18.01.2019
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:
gre2 - Klicke auf das Bild, um es zu vergrößern

MT IPsec Peer Setup für den Cisco:
gre23 - Klicke auf das Bild, um es zu vergrößern
gre24 - Klicke auf das Bild, um es zu vergrößern

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:
rip1 - Klicke auf das Bild, um es zu vergrößern
rip2 - Klicke auf das Bild, um es zu vergrößern
Routing Tabelle Cisco:
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 
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 !
Bitte warten ..
Ähnliche Inhalte
Windows Netzwerk
IPSec VPN oder GRE
gelöst Frage von winlinWindows Netzwerk21 Kommentare

Hi (2*gelöst)^34 Edit Biber Verkürzte "gelöst"-Schreibweise /Edit

Router & Routing
Routingproblem IPsec Tunnel
gelöst Frage von tvprog1Router & Routing3 Kommentare

Hallo, folgende Konstellation: Eine Firewall hat drei Interfaces (eth1, eth2 und eth3). eth1 (5.1.1.10/30) dient als Transfernetz zum Provider ...

Router & Routing

Jumbo-Frames über GRE-Tunnel i.V.m. MPLS möglich?

gelöst Frage von LordGurkeRouter & Routing3 Kommentare

Hallo, ich habe hier zwei Standorte, die normalerweise per angemieteter MPLS verbunden sind. Über diesen Transport sind auch Jumbo-Frames ...

Netzwerke

Ipsec VPN Tunnel RV110W - Bintec Be.IP

Frage von Zero01Netzwerke2 Kommentare

Hallo, kann mir jemand helfen eine IPsec LAN - LAN Verbindung zwischen diesen beiden Geräten auf zu bauen? Ist ...

Neue Wissensbeiträge
Windows Mobile

Support für Windows Mobile endet im Dezember 2019

Information von transocean vor 22 StundenWindows Mobile

Moin, Microsoft empfiehlt als Alternative den Umstieg auf iOS oder Android, wie man hier lesen kann. Gruß Uwe

Internet

Kommentar: Bundesregierung erwägt Ausschluss von Huawei im 5G-Netz - Unsere Presse wird immer sensationsgieriger

Information von Frank vor 2 TagenInternet5 Kommentare

Hier mal wieder ein schönes Beispiel für fehlgeleiteten Journalismus und Politik zugleich. Da werden aus Gerüchten plötzlich Fakten, da ...

Windows 10

Netzwerk-Bug in allen Windows 10-Versionen durch Januar 2019-Updates

Information von kgborn vor 3 TagenWindows 101 Kommentar

Nur ein kurzer Hinweis für Admins, die Windows 10-Clients im Portfolio haben. Mit den Updates vom 8. Januar 2019 ...

Windows 10

Windows 10 V1809: Rollout ist gestartet - kommt per Windows Update

Information von kgborn vor 3 TagenWindows 102 Kommentare

Eine kurze Information für die Admins, die Windows 10 im Programm haben. Microsoft hat die letzte Baustelle (die Inkompatibilität ...

Heiß diskutierte Inhalte
TK-Netze & Geräte
TAPI auf einem Win2016Server installieren und einrichten
Frage von wstabelTK-Netze & Geräte32 Kommentare

Hallo liebe Admins, ich habe folgende Situation: 1 Windows Server 2016 Standard als DC 1 SNOM 710 IP-Telefon 1 ...

E-Mail
Rechtssichere Archivierung von emails
Frage von gerd33E-Mail9 Kommentare

Hallo zusammen, bin gerade dabei, eine revisions- und rechtsichere email-archivierung aucf meinem Server zu projektieren. Da eigentlich nur ich ...

Netzwerkmanagement
Server bauen
Frage von JugendringNetzwerkmanagement9 Kommentare

Moin Moin, wir, der Jugendring sind ein ständig wachsender Verein mit vielen Unterprojekten. Da liegt es nah, dass wir ...

Off Topic
Darf ich ein Forum erstellen das Produkte eines Herstellers betrifft?
Frage von cyberwallOff Topic9 Kommentare

Hallo Community, ich habe da eine "rechtliche" bzw. allgemeine Frage zum erstellen von Foren. Darf ich als "normale Person" ...