Open-VPN auf APU zu langsam.
-
Es scheint als würde das OpenVPN jeweils einen Kern voll auslasten und damit in unserem Fall dann die Verbindung auf 30-40MBit begrenzen. Das reicht für mobile Anwender und VOiP-Telefone im Homeoffice aus. bei Site2Site nervt es weil auf beiden Seiten 100MBit synchron vorhanden sind und nur 1/3 davon wirklich ankommt.
Gibt es für "Site2Site" ein schnelleres Protokoll, was ich auf der PFSense nutzen kann?
Wenn ja, wo finde ich dazu ein "HowTo" ? -
@bitboy0
IPSec ist schneller. Am besten schaust du in die offizielle pfSense Doku für Anleitungen und Infos:
https://docs.netgate.com/pfsense/en/latest/vpn/performance.html -
Nun möchte ich Site2Site machen, aber eine Seite des Tunnels sitzt hinter einem NAT und hat keine feste IP
bei OpenVPN kein Problem, weil ich da einen Server und einen Client habe und der Client braucht keine feste IP.
Die Anleitung für IPsec geht aber von dem schönen Fall aus, dass beide Seiten eine feste IP haben und direkt am Netz hängen. Ich muss ja gleich zu Beginn auf Seite A die Adresse von Seite B (Remote gateway) angeben.
Oder hab ich das wieder nur nicht verstanden?
-
Nutzt du da keinen dynDNS Service?
Dann wäre dies der Anlass dafür. Man kann auch Hostnamen angeben. -
@bitboy0 said in Open-VPN auf APU zu langsam.:
Nun möchte ich Site2Site machen, aber eine Seite des Tunnels sitzt hinter einem NAT und hat keine feste IP
bei OpenVPN kein Problem, weil ich da einen Server und einen Client habe und der Client braucht keine feste IP.
Die Anleitung für IPsec geht aber von dem schönen Fall aus, dass beide Seiten eine feste IP haben und direkt am Netz hängen. Ich muss ja gleich zu Beginn auf Seite A die Adresse von Seite B (Remote gateway) angeben.
Oder hab ich das wieder nur nicht verstanden?
Moin.
Du kannst auch ein Hostname eingeben. Namensauflösung über DynDNS ist vorhanden?
edit:
@viragomann war schneller. :) -
So generell
Is ipsec im site2site Bereich wirklich openVpn vorzuziehen. -
Das war neu ein Teil der Antwort, die ich brauche.
Stelle B sitzt hinter einem NAT und kann von außen nicht erreicht werden. Sie kann aber überall hin verbinden.
Nur Seite A ist über ihre öffentliche IP auch direkt ansprechbar.
Also wird die Verbindung nur gehen, wenn Seite B sie initiiert. Geht das?
-
@bitboy0
Ich habe hier auch einen IPSec Router hinter der pfSense. Folgende Weiterleitungen musste ich dafür einrichten:- TCP/UDP WAN address Port 500 > IPSec-Host Port 500
- ESP WAN address > IPSec-Host
- UDP WAN address Port 4500 > IPSec-Host Port 4500
Das war der ganze Zauber.
-
@noplan said in Open-VPN auf APU zu langsam.:
Is ipsec im site2site Bereich wirklich openVpn vorzuziehen.
Man liest es immer wieder, auch von Netgate selbst.
Ich habe hier eine OpenVPN site-to-site für Backupzwecke, die ist langsam, soll aber gar nicht schneller sein, damit sie mit die WANs nicht zu sehr belastet.
-
@bitboy0
Richte zB dyndns auf B ein und fertig -
@viragomann said in Open-VPN auf APU zu langsam.:
Man liest es immer wieder,
Naja no denn
OpenVpn f die nomadic user und f site2site ipsec auch fein paaaasssst auch -
@noplan said in Open-VPN auf APU zu langsam.:
nomadic user
-
Is doch so... Die User die da draußen herumziehen und sich ins geheiligte corporate net verbinden.... ;)
HomeOffice kriegt bei uns jetzt eine apuBox und einen TPlink Switch zwecks der Trennung home & firma
-
;) Also absichtlich OVPN nutzen um den Traffic zu beschränken? ;)
Also noch Mal ... Site B ist nicht unser Netz und wir können dort keinen Port weiterleiten. DynDNS wird sicher gehen.
Können wir mit DynDNS, aber ohne Ports auf Site B ankommend zu öffnen oder weiterzuleiten, mit IPsec-Site2Site arbeiten?
-
Was hängt auf B vor der pfS?
Wenn das Modem whatever alles an die pfS weiterleitet dann kein Problem sonst musst du ein port weiterleiten von modem an pfSWie machst dyndns ohne auf das Modem zu greifen oder was da halt vor der pfS hängt
Die Verbindung von B z A aufbauen geht manchmal aber das kostet dich in der Wartung mehr Nerven als gut ist.
-
Ich kann dort nichts weiterleiten , weil das so ein sharedb Büro ist und da macht der Admin nichts dergleichen. und dyndns macht ich über ein eigenes Skript über ein Debian auf site A. Da bin ich Herr über den DNS. Also Aufbau muss zwingend von b nach a sein. Das war der Vorteil von openvpn, dass das bei b weder eine IP noch ankommende Ports nötig waren.
-
Das hab ich vermutet
Hatte sowas auch hab dann an unserem zugewiesenen Netzwerk anschl. Eine pfS box APU Box hingeklemmt und an die unseren switch geknalltSomit war unser Netz sauber
Zwar doppeltes NAT und eine kranke private IP aber was sollsKann dir jetzt nicht sagen obwir ports weitergeleitet bekommen haben oder ob wir on demand aufgebaut haben (was ich eher glaub)
Ich weiß nur das wir so ziemlich viel von unserem Netz ferngehalten haben -
@noplan said in Open-VPN auf APU zu langsam.:
So generell
Is ipsec im site2site Bereich wirklich openVpn vorzuziehen.Nö. Einfach Nö. Frag mal Leute die IPSec aus dem FF kennen bzw können müssen. Keine Sau will freiwillig IPSec.
Ist es schneller? Klar, Kernel vs User. Außerdem mehr Stellen für Multicore optimiert. Daher nicht so single core bound. Ist es besser? HELL NO! Es fuckt einen tierisch ab, wenn man jedes verdammte Mal wenn man einen dummen S2S Tunnel braucht erstmal diplomatische Beziehungen zur Gegenseite aufbauen muss um zu verhandeln, welche Einstellungen, welche Netze in P2, welche Features die abgefuckte Hardware unterstützt (in fucking 2020!) etc. etc. drekct.
Ich habs so satt (und bin krank und angepisst - daher mal so Rüde ausgedrückt).DAS ist der Scheiß Grund warum alle wie die Idioten auf Wireguard abgehen und mir ein Ohr abkauen deshalb. Weil WG dann (wenn es FERTIG ist) auch Kernel ist - daher schnell - und einfach konfiguriert werden soll (hopefully). Für Roadwarrior find ichs trotzdem schlecht weil auth etc ziemlich matsch ist. Aber S2S kann das echt was werden.
Aber deshalb mag keiner IPSec! -
Jop das war mir klar
Die diplomatische Beziehung kürzen wir immer ab weil wir nur Boxen aus unserer IT Diktatur verwenden ;)
Und ja du hast recht
-
Ich bin mit meinem Tunnel Netgate to Netgate mega zufrieden, das läuft in Hardware und man merkt nix das die Leitung gerade voll ausgelastet wird wenn ich ein NAS Backup fahre.
Wenn es also um reine Performance geht, du beide Endpunkte kontrollierst und du weißt was zu tun ist, ist IPSec auf kein Problem und in wenigen Minuten eingerichtet.
Wenn du das mit einem default Admin machen sollst, ohje. Aber mit so jemandem ist sehr viele mit ohje zu umschreiben.
Teste es doch einfach.
-
@NOCling said in Open-VPN auf APU zu langsam.:
Ich bin mit meinem Tunnel Netgate to Netgate mega zufrieden
Und ab da kannst du dir auf die Schulter klopfen und dich freuen :) Leider ist in der häufig anzutreffenden realen Welt/Szenarien die andere Seite meist HerstellerXYFuckUPFirewall23 der IPSec aus Jux und Dollerei gerade wieder mal Feature X ein- dafür aber Feature Y ausgebaut hat. ARGH.
Wenn es also um reine Performance geht, du beide Endpunkte kontrollierst und du weißt was zu tun ist, ist IPSec auf kein Problem und in wenigen Minuten eingerichtet.
Agreed :)
Und sorry über den IPSec Rant, aber es kotzt auf Dauer einfach nur an ;)
-
So viel Ärger haben wir mit unseren zentralen Tunneln gar nicht, die Einrichtung mag das einen oder andere mal interessant sein, je nach Qualität des Mitarbeiters der Gegenstelle.
Aber wenn die mal laufen, dann laufen die bei uns und der einen oder andere rostet so langsam in der config fest.
-
@viragomann said in Open-VPN auf APU zu langsam.:
ESP WAN address
Also Wireguard wäre mutmaßlich dafür gut weil schnell und einfacher zu implementieren. Gibts bei OpenSense, aber auf unbestimmte Zeit nicht bei PFSense.
IPsec will am besten feste IPs und auf beiden Seiten offene Ports
OpenVPN ist weniger anspruchsvoll bei der Config, funktioniert zuverlässig und ist nie so schnell wie man es gerne hätte.@JeGr Wann genau ist WireGuard fertig? ;)
-
@bitboy0 said in Open-VPN auf APU zu langsam.:
funktioniert zuverlässig und ist nie so schnell wie man es gerne hätte.
ja da kann ich zustimmen !
bei IPsec haben wir mit dynamischen Adressen auch so unsere problemchen ...
wusste gar nicht das wir fast alles von IPsec auf openVPN umgestellt haben ... -
Hmm, ihr habt dann kein IKEv2 mit Mobike eingerichtet oder?
Habe hier ja auch immer wieder mal eine neue IP und auf beiden Seiten Dyndns, seit Einrichtung läuft der Tunnel wenn mir nicht mal wieder die Cabel Strecke zum CMTS um die Ohren fliegt.
Aber es kann auch an der Sense liegen, die das einfach sauber umsetzt und nicht son Gurken GW representiert. - 10 days later
-
@bitboy0 said in Open-VPN auf APU zu langsam.:
Also Wireguard wäre mutmaßlich dafür gut weil schnell und einfacher zu implementieren. Gibts bei OpenSense, aber auf unbestimmte Zeit nicht bei PFSense.
IPsec will am besten feste IPs und auf beiden Seiten offene Ports
OpenVPN ist weniger anspruchsvoll bei der Config, funktioniert zuverlässig und ist nie so schnell wie man es gerne hätte.Ja, OPNsense hat Wireguard - solala implementiert. Wer da mitliest - und ich mache deren deutsches Forum ja auch - sieht, dass es da häufig mal knallt. Großen Geschwindigkeitsbonus kann es technisch momentan nicht geben (weil keine Kernel Implementation) und ständig dran rumschrauben weil mal wieder was nicht geht nach Update X - das ist nicht stabil. Für einen fire&forget Einsatz ist mir das zu vage. Klar tolle Spielerei für zu Hause! :) Aber im Dauereinsatz - nee.
OpenVPN hatte ich seltenst Speedprobleme. Könnte aber dran liegen, dass ich selten Hardware am unteren Limit nutze, die dann immer gleiche überfordert ist.
Dafür sagen selbst IPsec und IPv6 Spezis (letztens erst wieder auf ner Konferenz): wenn du Masochist bist, nutz ruhig IPsec, wenn du einfach willst dass was läuft, nutz OpenVPN und gut.@JeGr Wann genau ist WireGuard fertig? ;)
Wenn es in FreeBSD im Kernel fertig ist. Kann jeder selbst mitlesen. Netgate hat Code dafür an Upstream schon reingereicht damit man daran arbeiten kann. Aber es gibt eben noch keine fertige Kernelmodul/-extension. Und selbst dann: Wireguard mag dann schön sein und einfach für S2S Szenarien.
Für Roadwarrior Einsatz die über "darf alles daheim" raus geht, ist Wireguard - nicht nur mir - immer noch suspekt, weil es bislang keine großartigen Client Auth Mechanismen gibt. War u.a. auch Gespräch im Talk mit einigen FreeBSD und OPNsense Leuten den ich vor einem knappen Monat hatte. Klar sind alle gehypet auf was Neues aber da muss man auch ein bisschen Salz mitnehmen und das sehr genau beäugen, ob das so toll ist und was bringt. Es kann sicher sehr gut werden(!), momentan fehlt da aber IMHO noch ein paar Sachen, die andere VPNs schon lange implementiert haben. Was bringt mir bspw. super einfache Einrichtung und Geschwindigkeit, wenn ich die Clients nicht authentifizieren kann und ggf. eine IP zuweisen oder eingrenzen oder in Netzen einsperren kann um deren Zugriff zu limitieren? :)
-
Okay, Danke!
.... Dann bekämpfe ich eben das lahme OpenVPN mit CPU-Power und spare mir den Kampf mit IPsec und muss auch nicht auf Wireguard hoffen.Frage:
Gibt es eine APU-Platine die schnell genug ist für stabile 100+MBits S2S mit OpenVPN?
Wir haben zur Zeit zwei Sensen im Cluster. Da müsste ich die Config dann drauf spielen... Also was mit 3 NICs wäre erforderlich.
WAN,LAN,CARP.
APU wäre schick, weil wir da ein 19" Gehäuse für die zwei Sensen haben.
Welche Hardware würde man da einsetzen, wenn eine APU keine Alternative ist?
Und bitte keine Hardware, die man nur mit Wartungsvertrag bekommt. Ich zahle gerne Support bei Bedarf und möchte keine zusätzlichen laufenden Kosten. -
@bitboy0 said in Open-VPN auf APU zu langsam.:
Gibt es eine APU-Platine die schnell genug ist für stabile 100+MBits S2S mit OpenVPN?
Wenn du die pcEngines APU meinst - nein. Es gibt nur EINE APU Platine. Mehr haben sie nicht. Alle anderen Varianten mit Zahlen ist die gleiche Hardware. Egal ob APU2, APU3 oder APU4 es ist immer der gleiche dusselige steinalte AMD Jaguar da drauf. Die haben nix Neueres.
Wenn du generell APU meinst im Sinne von CPU+GPU als SOC: da gibts einige die das locker packen. Ist aber natürlich eine Finanzfrage :)
Ah, jetzt erst gelesen (blind, sorry), das 19" APU Gehäuse etc. - also nein, die PCEngines APUs sind einfach zu schwach.
3 NICs sind heute weniger Problem. Wenn aber das Ziel wirklich 100%ig ist, dass ihr 100Mbps Durchsatz encrypted auf nem VPN Tunnel wollt (und die andere Seite das auch bringt/kann! - bringt ja nix, wenn die Gegenseite zu lahm ist), dann wäre das der Punkt, den man als SOC suchen müsste. C2000 ist alt und würde ich nicht mehr empfehlen, wobei da die großen IMHO auch schon auf 100Mbps locker gekommen sind. Ansonsten sind C3000er auf jeden Fall problemlos in der Lage das zu stemmen. Also C3558 oder C3758 o.ä. - je nachdem was man sonst noch einsetzen möchte. Evtl. gehts aber auch kleiner wenn wirklich nur VPN der Knackpunkt ist. Aber wie gesagt, dann muss auch die Gegenstelle mitziehen. Wenn die bspw. eh nur 25 oder 50 schafft, kann man da andere Maßstäbe ansetzen :)