"Scan to Folder" durch IPSec Tunnel geht nach Umstellung auf pfsense nicht mehr

[papa_joe]

Hallo.

Mein erster Post - und dann auch noch sowas :-.

Ich versuche durch einen IPSec Tunnel zu scannen (scan to folder), was parout nicht mehr funktionieren will. Aber der Reihe nach …

SiteA: CentOS 6.6 Openswan
SiteB: pfSense 2.2.2

Zwischen den beiden Standorten gibt es ein IPSec VPN, welches die Netze 192.168.50.0/23 (NetzA) und 192.168.90.0/23 (NetzB) verbindet. Es sind keine Firewall-Einschränkungen für den Tunnel definiert. Am Wochenende habe ich einen Draytek Router (SiteB) durch die pfSense (SiteB) abgelöst. Es funktioniert auch alles, bis auf scan-to-folder auf W2K12R2 und Samba Server von den Multifunktionsgeräten aus NetzB nach NetzA. Normalerweise würde ich das hier wohl nicht posten, wenn ich nicht schon alles mögliche probiert hätte um den Fehler zu finden und langsam am verzweifeln bin. Da der Fehler erst nach Umstellung auf pfSense auftritt, suche ich das Problem dort - hoffentlich hat hier noch jemand eine Idee.  :-[

Folgender Status:

• Scannen von mehreren MuFu NetzB zu Server NetzA (egal ob Windows oder Samba Server) funktioniert nicht, es entsteht je eine Datei mit 0kb Größe und dann ist Schluß
• Scannen von mehreren MuFu NetzB zu Freigabe im NetzB funktioniert einwandfrei
• Mounten einer Freigabe auf dem Server NetzA von einem PC aus dem NetzB geht problemlos. Verwendet wurde der Nutzer der MuFu-Geräte. Ebenso lassen sich Dateien in der Freigabe anlegen, editieren, löschen.

Anbei noch die Einstellungen der Firewall der pfSense. Ebenso die States beim Verbindungsaufbau. Dann noch ein tcpdump-Log auf der Firewall SiteA, eingeschränkt auf die IP des MuFu in NetzB.

Hilfe  :-, wo mache ich weiter?

tcpdump_log.txt

[papa_joe]

Ich antworte mir mal selbst, da ich neue Erkenntnisse habe.

Das Problem tritt nur auf, wenn der IPSec-Tunnel über NAT-T UDP 4500 aufgebaut wird. Normal über UDP 500 geht es problemlos, aber leider konnte ich das nur zum testen mal auf die andere Leitung switchen. Hauptanschluss ist ein Kabelanschluß mit privater IPv4, da komme ich um NAT-T nicht rum. Das Phänomen lässt sich aber auch nachstellen, wenn man öffentliche IP's an beiden Endpunkten hat, aber NAT-T beim Verbindungsaufbau erzwingt. Es liegt also auch nicht am Kabelprovider. Ich habe auch einen Tunnel zwischen zwei pfSense aufgebaut, dort besteht das Problem auch, ich kann also die CentOS Firewall auch als Fehlerquelle ausschließen.

Ich habe noch was anderes festgestellt, wenn NAT-T für den Tunnel verwendet wird. Aus NetzA kann man dann auch nicht auf ein WebGUI (z.B. des Scanner, MuFu, o.ä.) in NetzB zugreifen. Man bekommt z.T. noch die htaccess Auth-Abfrage und dann ist Schluß. Reproduzierbar. Ob es auch von NetzB zu NetzA so wäre kann ich nicht sagen, ich habe dort leider kein entprechendes Gerät stehen.

Kann das evtl. jemand verifizieren? Ist es mein Fehler (Einzelfall  ;) ) oder ein Bug?

PS: Testweise auch über OpenVPN probiert -> keine Probleme.

[papa_joe]

Ich führe meinen Monolog mal noch ein bisschen weiter - vielleicht findet ja doch noch jemand einen Ansatzpunkt.

Nach Tests vieler unterschiedlicher Szenarien kann ich nun folgendes sagen:

Geräte:
pfSense1 = phys. pfSense (Dual WAN: Kabel (NAT) und CompanyConnect)
pfSense2 = phys. pfSense (T-DSL)
pfSense3 = virt. pfSense (Hetzner RZ, Test)
OpenSwan = phys. CentOS6.6 (Hetzner RZ)

Wenn man IPSec mit NAT-T aufbaut, bekomme ich folgendes Ergebniss:

Funktioniert:
pfSense1 <-> pfSense2

Funktioniert nicht:
pfSense1 <-> pfSense3
pfSense1 <-> OpenSwan
pfSense2 <-> pfSense3
pfSense2 <-> OpenSwan

Was habe ich gelernt: Man sieht, die Fehler bestehen nur bei Verbindungen zu Hetzner.

Ich habe nur keine Ahnung was ich mit dieser Erkenntnis anfangen soll, ich finde einfach keinen Hinweis wie ich das Phänomen weiter eingrenzen, geschweige denn beheben könnte.

Doch jemand mit Ideen dazu hier?

[JeGr]

Und an Konfiguration des Tunnels sind sich pfs1/2/3 gleich? Also Phasen, Netze, etc.?

[papa_joe]

Ja, ist gleich.

Ich habe jeweils nur die Remote-IP für Phase1 geändert, das war's. Phase2, Firewall - nix angefasst. Ich habe dort, wo ich eine öffentliche IP hatte, auch immer den Test mit und ohne NAT-T gefahren. Ohne geht alles prima, mit NAT-T geht eben manches nicht mehr.

Totales Rätsel …

[papa_joe]

Es funktioniert !!!  ;D

Mir gingen auch langsam die Strohhalme zum festhalten aus.

Gebracht hat es jetzt die Option "Enable MSS clamping on VPN traffic" in den IPSec Advanced Settings. Ich habe den Wert erstmal auf 1300 eingestellt und schon fliegen die Daten.

Jetzt, da ich des Rätsels Lösung kenne, würde ich gern noch der Ursache auf den Grund gehen. Dazu brauch ich nochmal Hilfe. Wie kommt es, dass die Verbindung zu Hetzner eine andere MTU hat, wie z.B. von T-DSL -> Primacom Kabel, oder was auch immer? Wieso unterscheidet sich die MTU, ob ich IPSec "normal" oder über NAT-T fahre? Wie kann ich jetzt herausfinden, was der optimale Wert ist, den ich einstellen sollte?

???

[JeGr]

ob ich IPSec "normal" oder über NAT-T fahre?
Verbindung zu Hetzner eine andere MTU hat, wie z.B. von T-DSL -> Primacom Kabel

MTU size. Bei DSL bspw. ist diese immer geringer als die normale Ethernet Size von 1500. Bei NAT-T wird durch entsprechende Tricks VPN hinter NAT möglich, indem Pakete wieder zusätzlich eingepackt werden. Bei DSL ist die max MTU eh schon geringer als 1500.

Evtl war es wirklich so dass sich die Tunnel an DSL/Kabel orientiert haben, Hetzner Seite aber durch direkte Anbindung an Ethernet mit 1500 agiert hat und dementsprechend immer Pakete fragmentiert hat. Schwer zu sagen. Ich würde mich jetzt noch rantasten, ab welchem Wert er nicht mehr läuft. Du könntest bei 1500 oder 1450 anfangen beim Aufbau und dann Pings probieren mit weniger Payload bis es funktioniert.

[papa_joe]

Ich habe den Wert inzwischen auf 1350 eingestellt und fahre gut damit.

Wenn man weiß, nach was man sucht, wird man sogar in den pfSense Docs fündig:  ::)

https://doc.pfsense.org/index.php/IPsec_Troubleshooting#Packet_Loss_with_Certain_Protocols

Ich danke Dir!