Site to Site VPN zwischen pfSense und Fritzbox - Tunnel steht aber keine Daten gehen durch

BLinz

Moin,

zufällig habe ich genau die gleichen Probleme. Und zufällig bin ich der Ersteller der von dir verlinkten Anleitung.
Ich habe in letzter Zeit mehrere Abende damit verbracht das Problem zu Lösung ... und bin gescheitert.

Meine FritzBox 7390 (FRITZ!OS 06.83) ist zwar zusätzlich hinter einem Telekom Hybrid-Router und ich hatte diesen in Verdacht. Immer nach dem trennen und wiederherstellen der DSL Verbindung ging es wieder ... für eine Weile.
MIch habe auch alles mögliche an der IPSec-Verbindung ausprobiert - hat auch nicht geklappt. Nach vielen Fummeln (In der FritzBox gelöscht und neu verbunden) geht es zwischendurch mal - ist eher Zufall. Wenn es klappt dann nach einiger Zeit (Minuten bis Stunden) nicht mehr - und kommt auch von alleine nicht wieder hoch.

Die Verbindung ist eigentlich auch nicht das Problem. Der Tunnel baut sich zuverlässig auf und steht. Aber wie bei dir geht nichts durch. Laut dem Status auf der pfSense funktioniert der Tunnel in eine Richtung nicht, die hat dann keinen Traffic mehr.
Das ganze hat fast 3 Jahre ohne Probleme funktioniert, auch mit dem FritzOS seit dem es raus ist .... und ich kann nicht sagen was jetzt anders ist.

Ich habe eine 2. FritzBox die ebenfalls ein IPsec zur pfSense aufbaut - von EWE und deshalb mit einer älteren Firmware. Die läuft scheinbar ohne Probleme.

Inzwischen habe ich mir ein APU2C4 Kit gekauft und baue den Tunnel nicht mehr über die FritzBox und IPSec auf sondern zwischen 2 pfSense und OpenVPN. Und das sogar als "TCP4" , ob es hier auch mit UDP Probleme gibt teste ich dieser Tage.

Welchen Provider hast du? FritzBox ist direkt angeschlossen?

Bernhard

Gladius

@blinz said in Site to Site VPN zwischen pfSense und Fritzbox - Tunnel steht aber keine Daten gehen durch:

Inzwischen habe ich mir ein APU2C4 Kit gekauft und baue den Tunnel nicht mehr über die FritzBox und IPSec auf sondern zwischen 2 pfSense und OpenVPN. Und das sogar als "TCP4" , ob es hier auch mit UDP Probleme gibt teste ich dieser Tage.

Was soll denn gegen OpenVPN/"TCP4" sprechen? In einem Roadwarrior Szenarium hat TCP sogar Vorteile gegenüber UDP.
OpenVPN/TCP getunnelt über SSL funktioniert bei ausreichend leistungsfähiger Hardware ohne Probleme.

Wie sieht es denn mit der OpenVPN Leistung einer APU2C4 aus? Wo sind die Grenzen des SoC GX-412TC?

viragomann

@gladius
OpenVPN via TCP hat nur dann einen Vorteil, wenn UDP nicht machbar ist, bspw. wenn die Clients die Verbindung aus eingeschränkten Hotspots aufbauen wollen, die UDP nicht erlauben. Dann ist zumeist aber auch Port 1194 nicht erlaubt und man muss auf einen der Standardprotokolle HTTP/S, SMTP/S ausweichen.

Die Nachteile von TCP wären eher durch eine höhere Leitungsbandbreite denn durch stärkere Hardware wettzumachen, doch darauf hat man nicht immer Einfluss.

Grüße

Gladius

@viragomann said in Site to Site VPN zwischen pfSense und Fritzbox - Tunnel steht aber keine Daten gehen durch:

Die Nachteile von TCP wären eher durch eine höhere Leitungsbandbreite denn durch stärkere Hardware wettzumachen, doch darauf hat man nicht immer Einfluss.

Diese Bemerkung bezog sich auf OpenVPN getunnelt über SSL. Okay, das wird nicht jeder einsetzen,
funktioniert aber problemlos mit entsprechender Hardware.

LG

BLinz

@gladius said in Site to Site VPN zwischen pfSense und Fritzbox - Tunnel steht aber keine Daten gehen durch:

Wie sieht es denn mit der OpenVPN Leistung einer APU2C4 aus? Wo sind die Grenzen des SoC GX-412TC?

Kann ich leider nicht testen. Da die CPU aber AES-Beschleunigung bietet, pfSense diese laut eigener Anzeige (nach manueller Aktivierung) auch nutzten kann und laut meinem Gedächtnis OpenVPN diese ab Werk nutzt sicherlich einiges.
Ich habe hier nur einen Telekom Hybrid mit etwa 65MBit Down und 10MBit Up. Wenn ich etwas durch den Tunnel pumpe steigt die CPU-Last nur wenig und liegt so bei 60 bis 150 MHz (von 1.000 Möglichen).

Die APU-Büchse ist aber recht genial. Ich habe einen VMware ESXi drauf gesetzt und lasse eine pfSense (2vCPU/512MB RAM), eine Ubuntu 18.04 VM mit Pi-Hole (2vCPU,512MB RAM) und einen Windows Server 2016 Server als Domänencontroller (2vCPU, 1GB RAM) drauf laufen. Der Windows Server schwächelt bei Updates, die großen (>1GB) habe ich von Hand eingespielt. Ist halt "nur" eine 4 x 1GHz CPU. Ich habe eine mSATA SSD und eine normal SATA SSD drin (2,5" SSD passt lose mit ins Gehäuse, SSD ist aus Kunststoff daher keine Kurzschlussgefahr). Die Plattenperformance ist nicht so gut, geht aber.

Ich habe einen Raspberry Pi 3 der als zweiter Pi-Hole Server läuft. Der wirkt etwas flotter als meine Ubuntu-VM, aber es geht. Meinen bisherigen "Server" (normaler Windows PC) kann ich jetzt theoretisch einmotten und habe es besser als zuvor.

Gladius

@blinz said in Site to Site VPN zwischen pfSense und Fritzbox - Tunnel steht aber keine Daten gehen durch:

Da die CPU aber AES-Beschleunigung bietet, pfSense diese laut eigener Anzeige (nach manueller Aktivierung) auch nutzten kann und laut meinem Gedächtnis OpenVPN diese ab Werk nutzt sicherlich einiges.

Wenn man OpenVPN einsetzt, wird OpenVPN/OpenSSL automatisch die Möglichkeiten der CPU bzgl. AES-NI nutzen.
Die Aktivierung des Moduls AES-NI betrifft IPsec. Es ist also für die OpenVPN-Leistung ohne Belang ob der
Modul AES-NI geladen ist.

viragomann

@gladius
In Advanced > Miscellaneou sollte AES-NI schon aktiviert werden, damit es genutzt wird.

Ich zittiere aus https://www.netgate.com/docs/pfsense/hardware/cryptographic-accelerator-support.html:
"Others, such as AES-NI or glxsb on ALIX require choosing the appropriate module under System > Advanced on the Miscellaneous tab. Choose the appropriate module to match the hardware for Cryptographic Hardware and then Save. The module will be loaded and available immediately."

Gladius

Ich habe in einem anderen Thema die Leistung von OpenVPN auf meiner Hardware ausgiebig getestet und ich stehe
zu meiner Aussage:

OpenVPN/OpenSSL ist es egal ob der Modul AES-NI geladen ist oder nicht. Wer etwas mehr Leistung mit OpenVPN
erreichen will sollte AES-GCM statt AES-CBC nutzen.

Gladius

Abschließend von mir zum Thema OpenVPN und AES-NI stelle ich eine Bemerkung von
pfSense (pfsense-ivork) in den Raum und beziehe mich auf diese Internetquelle:

https://www.reddit.com/r/PFSENSE/comments/7931o7/pfsense_241_crypto_question

"OpenVPN uses AES-NI automatically if the CPU is compatible."

johndo

Hallo zusammen,

habe mich dazu entschieden noch eine pfsense aufzusetzen und dann das VPN aufzubauen. Das mit der Fritzbox geht mir etwas auf die Nerven :).

JeGr

@gladius said in Site to Site VPN zwischen pfSense und Fritzbox - Tunnel steht aber keine Daten gehen durch:

Abschließend von mir zum Thema OpenVPN und AES-NI stelle ich eine Bemerkung von
pfSense (pfsense-ivork) in den Raum und beziehe mich auf diese Internetquelle:

https://www.reddit.com/r/PFSENSE/comments/7931o7/pfsense_241_crypto_question

"OpenVPN uses AES-NI automatically if the CPU is compatible."

Da bezieht sich ivor aber auf eine ganz andere Fragestellung. Es bleibt aber festzuhalten, dass bei den RC Tests zu Beginn von 2.4 bereits klar gestellt wurde, dass das beste Geschwindigkeitsverhältnis mit der damaligen OVPN 2.4 Version mit geladenem AES-NI UND Cryptodev Modul erreicht wurde. Dazu gab es im RC Thread auch mehrere Benchmarks die das klar belegt haben, dass die Kombination von beidem am Sinnvollsten ist.

Die Bemerkung dass OVPN via OpenSSL das ganze selbst aussucht ist aber korrekt, da OVPN hier kein Kernelspace nutzt sondern via Software und OpenSSL das selbst feststellt und nutzt. Auch sollte man - wenn man beide Enden kontrolliert und aktuelle OVPN Versionen laufen - beide mit GCM lösen, was nochmal Performance rauskitzeln kann :)

Haben also (fast) alle mit allem recht ;)

Gladius

@jegr said in Site to Site VPN zwischen pfSense und Fritzbox - Tunnel steht aber keine Daten gehen durch:

Auch sollte man - wenn man beide Enden kontrolliert und aktuelle OVPN Versionen laufen - beide mit GCM lösen, was nochmal Performance rauskitzeln kann :)

Diese Erfahrung habe ich bei meinen Tests auch gemacht. Weitere Infos dazu.

Als Randbemerkung folgender Fakt:
OpenVPN/TUN/TCP lieferte bessere Werte bei meinen Tests als OpenVPN/TUN/UDP. Dafür habe ich keine Erklärung.

alexander90

Gibt es hier zum Ursprungsproblem schon eine Lösung?

JeGr

Da sich @johndo schon ewig nicht mehr gemeldet hat, glaube ich das nicht. Allerdings ist sowohl die verlinkte Anleitung als auch die Aussagen teils mehr als überholt.

Aktuell gerade heute morgen bei einem Kunden zwangsweise eine FritzBox zu pfSense 2.4.4 Strecke in Betrieb genommen. Die verwendete Box hatte 6.93 als OS drauf und konnte damit, im Gegensatz zu vielen anders kursierenden Antworten im Netz:

Auch OHNE das AVM Tool direkt in der UI für VPN konfiguriert werden (allerdings sehr wenig und mies aber es geht)
Konnten innerhalb einer halben Stunde den Tunnel einrichten (allerdings geht nur eine Phase 2 pro Tunnel)
Funktioniert zumindest AES256 mit SHA1 (leider kein SHA256) mit DH2 (leider kein DH14 von der Box angeboten worden)

Ein Downsizing der Crypto auf 3DES oder AES128 wie es viele aber immer noch propagieren ist unnötig. Lediglich SHA1/DH2 sind schlecht, hier könnte aber ggf. das Update auf OS 7.01 Abhilfe bringen bzw. wenn man die Konfiguration mit dem AVM Tool erstellt sind ggf. andere Settings möglich als direkt nur in der sehr abgespeckten UI.

Grüße

alexander90

Danke dir! Ich hatte es bislang immer nur mit dem AVM-Tool probiert und es leider nicht zum laufen gebracht. Über die Web-GUI funktioniert es aber.

PS: Die Fritzbox hatte auch schon OS 7.01 drauf.

JeGr

@alexander90 said in Site to Site VPN zwischen pfSense und Fritzbox - Tunnel steht aber keine Daten gehen durch:

Danke dir! Ich hatte es bislang immer nur mit dem AVM-Tool probiert und es leider nicht zum laufen gebracht. Über die Web-GUI funktioniert es aber.

Jap, bei dem AVM Tool muss m.W. auch noch das ein oder andere dann händisch umgestrickt werden im File bevor es wieder eingespielt wird, dann sollen auch bessere Cipher/Hashes laufen aber die o.g. haben zumindest auf Anhieb über die UI funktioniert.

Randnotiz: Seltsamerweise war die Kundenbox so drauf, dass sie die Verbindung selbst nie aufbauen konnte (Fehlermeldung im Syslog laut AVM: Auth Token falsch, also der PSK inkorrekt). Sobald die andere Seite die Verbindung aber aufgebaut hat (einmal mit einer alten Kunden-Endian-Instanz und dann mit der neuen pfSense getestet) lief alles problemlos. Schade dass das so ein Problemkind bleibt. Wenn man die Box auf "Receive only" stellen könnte, wäre es sicher einfacher, den Tunnel schnell aufgebaut zu bekommen, so machte er immer 3-5min lang Probleme bis die FB die Versuche einstellt und die pfSense ran lässt ohne "dazwischenzuquatschen". ;)