Hallo zusammen,
ich habe aktuell die Problematik, dass ich problemfrei eine Peer-to-Peer-(shared Key)-VPN-Verbindung zwischen zwei OPNsense (21.7.7) am laufen habe. Im Tunnelnetzwerk 10.230.13.0/24 erhält die Client-Firewall die virtuelle IP-Adresse 10.230.13.2 und die Server-Firewall die virtuelle Adresse 10.230.13.1.
Stelle ich lediglich den Servermodus auf "Peer-to-Peer (SSL/TSL)" (CA-Cert und Client-Cert entsprechend vorher angelegt und verteilt) funktioniert der Verbindungsaufbau nach wie vor ... komischer Weise erhält die Client-Firewall dann die virtuelle IP-Adresse 10.230.13.5 und das Routing funktioniert über die VPN-Verbindung nicht mehr sauber.
Kennt jemand diese Problematik? Mich wundert, dass die Client-Firewall nicht (wie üblich) die erste IP-Adresse (nach dem Gateway) in dem Tunnel-Subnetz, sprich 10.230.13.2 (wie bei shared-Key, wo alles geht) erhält.
Schöne Grüße und besten Dank,
mscd
Erstellt den VPN Server mal neu und dann direkt mit Peer2Peer TLS.
Kommt es dann immernoch vor?
Gesendet von meinem M2012K11AG mit Tapatalk
Bei Zertifikaten musst du einen Client specific override erstellen und dort local und remote hinterlegen.
Okay ... besten Dank ... das hat geholfen (nun klappt es auch im SSL/TLS-Modus).
Noch eine kleine Rückfrage ... die OPNsense läuft aktuell auf einem dedizierten Root-Server als VM in Proxmox (mit AESni-Support), welcher mit 1 GBit/s symmetrisch angebunden ist. Die Gegenstelle hängt an einem Kabelmodem mit 1 GBit/s im Downstream auf dedizierter (potenter) Hardware (eine ehemalige Sophos SG310).
Was mich aktuell etwas verwundert ... der maximale OpenVPN-Durchsatz pendelt so bei 40 MBit/s ?! ... und zwar in dem Fall, wenn ich Daten vom Root-Server in Richtung Kabelmodem sende, sprich da müssten (theoretisch) im Idealfall 1000 MBit/s durchgehen.
Gegentest mit deaktivierter Encryption + Authentifizierung hat keinen Unterschied ergeben.
CPU-Last pendelt bei beiden Maschinen auf unter 25%.
Was ist hier zu "erwarten"? Ich finde gerade das Bottelneck nicht.
Danke und Grüße,
mscd
Bei virtuell ist das immer etwas schwierig einzugrenzen. Bei Xeon und Blech sollten ca. 800 Mbit drin sein
Ok ... klar mit "virtuell" ... aber durch das gleiche virtuelle Gateway gehen an die VMs dahinter mit nperf getestet 950 MBit/s symmetrisch. Sprich an den Interfaces usw. kann es nicht liegen ... und bei deaktivierter Verschlüsselung im VPN wohl auch nicht an der Virtualisierung von AESni.
Sehr komisch.
Grüße,
mscd
Trotzdem muss jedes Paket durch den Userspace,egal ob verschlüsselt oder plain. Das kostet halt
So ... frischer "Gegentest" mit IPsec-S2S"-Verbindung ... und man siehe ... 500 statt 50 Mbit/s (mit aktiver Verschlüsselung) ... woran es liegt ... kann ich derzeit auch nicht sagen. An der Performance der VMs kann es aber schon mal nicht liegen.
Grüße,
mscd
Doch, IPsec muss nicht in den userspace .. und 500mbit ist bei IPsec auch nicht sooo berauschend.