3
PfSense OVPN: kein Zugriff nach Wechsel auf VirtIO
Hallo zusammen,
ich habe da mal ein kleines Problem:
Ich habe eine virtualisierte pfSense. Auf dieser pfSense läuft ein OpenVPN-Server und ein Site-to-Site-VPN mit meinem Heimrouter. Dieses funktionierte auch einwandfrei... Bis jetzt...
Um die Performance zu steigern, habe ich die pfSense auf VirtIO umgestellt und die Interfaces entsprechend neu zugewiesen...
Die OpenVPN-Verbindung wird auch wiederhergestellt, ich kann auch alle Hosts im Remote-Netz anpingen, aber ich bekomme keine SSH, HTTP, etc-Verbindung zustande. Diese bricht immer mit einem Timeout ab. Auf das Webinterface der pfSense kann ich zugreifen. Von der pfSense aus funktioniert auch der SSH-Zugriff auf einen Host im lokalen Netz.
Wenn ich das Interface wieder auf ein E1000 umstelle, funktioniert der Zugriff auch wieder.
Hat jemand eine Idee, woher dieses Problem rühren könnte? Ich steh grade echt auf dem Schlauch.
Beste Grüße!
Berthold
ich habe da mal ein kleines Problem:
Ich habe eine virtualisierte pfSense. Auf dieser pfSense läuft ein OpenVPN-Server und ein Site-to-Site-VPN mit meinem Heimrouter. Dieses funktionierte auch einwandfrei... Bis jetzt...
Um die Performance zu steigern, habe ich die pfSense auf VirtIO umgestellt und die Interfaces entsprechend neu zugewiesen...
Die OpenVPN-Verbindung wird auch wiederhergestellt, ich kann auch alle Hosts im Remote-Netz anpingen, aber ich bekomme keine SSH, HTTP, etc-Verbindung zustande. Diese bricht immer mit einem Timeout ab. Auf das Webinterface der pfSense kann ich zugreifen. Von der pfSense aus funktioniert auch der SSH-Zugriff auf einen Host im lokalen Netz.
Wenn ich das Interface wieder auf ein E1000 umstelle, funktioniert der Zugriff auch wieder.
Hat jemand eine Idee, woher dieses Problem rühren könnte? Ich steh grade echt auf dem Schlauch.
Beste Grüße!
Berthold
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 267225
Url: https://administrator.de/contentid/267225
Printed on: April 26, 2024 at 08:04 o'clock
3 Comments
Latest comment
Hallo,
Unterstützung hat, sollte das schon wesentlich schneller laufen!
die beiden beteiligten Seiten, sollten eben diese performant abhandeln können!
Was nützt es also wenn Du auf der einen Seite die Verbindung beschleunigst und
auf der anderen Seite ist dann nur der "Heimrouter" und der bremst dann die VPN
Verbindung wieder aus!
FreeBSD Foundation announces IPsec Enhancement Project
New modes include AES-CTR and AES-GCM with hardware acceleration using Intel’s AES-NI
instructions. According to John-Mark, “on a modern 64-bit x86 CPU one core can process about
1 gigabyte per second of data” using the new AES-GCM mode.
pfSense AES-NI accelerated IPSec in 2.2
o this is, in many-respects, a "real world" test, not an artificial "in-the-lab" test.
I'm seeing between 729mbps and 891mbps throughput in the below.
Netgate C2758
OpenVPN (AES-256 TCP 116 UDP 208
OpenVPN (AES-128) TCP 120 UDP 218
Gruß
Dobby
Ich habe eine virtualisierte pfSense.
Das ist schon mal kontraproduktiv, denn nativ auf einer Hardware mit Intel CPU die AES-NiUnterstützung hat, sollte das schon wesentlich schneller laufen!
Auf dieser pfSense läuft ein OpenVPN-Server und ein Site-to-Site-VPN
Und verrätst Du uns auch welche Verschlüsselungsstärke benutzt wird?mit meinem Heimrouter. Dieses funktionierte auch einwandfrei... Bis jetzt...
Also eine VPN Verbindung ist immer eine Punkt-zu-Punkt Verbbindung unddie beiden beteiligten Seiten, sollten eben diese performant abhandeln können!
Was nützt es also wenn Du auf der einen Seite die Verbindung beschleunigst und
auf der anderen Seite ist dann nur der "Heimrouter" und der bremst dann die VPN
Verbindung wieder aus!
Um die Performance zu steigern, habe ich die pfSense auf VirtIO umgestellt
und die Interfaces entsprechend neu zugewiesen...
Welchen Durchsatz hast Du denn bis dato?und die Interfaces entsprechend neu zugewiesen...
FreeBSD Foundation announces IPsec Enhancement Project
New modes include AES-CTR and AES-GCM with hardware acceleration using Intel’s AES-NI
instructions. According to John-Mark, “on a modern 64-bit x86 CPU one core can process about
1 gigabyte per second of data” using the new AES-GCM mode.
pfSense AES-NI accelerated IPSec in 2.2
o this is, in many-respects, a "real world" test, not an artificial "in-the-lab" test.
I'm seeing between 729mbps and 891mbps throughput in the below.
Netgate C2758
OpenVPN (AES-256 TCP 116 UDP 208
OpenVPN (AES-128) TCP 120 UDP 218
Gruß
Dobby
Zitat von @108012:
Hallo,
> Ich habe eine virtualisierte pfSense.
Das ist schon mal kontraproduktiv, denn nativ auf einer Hardware mit Intel CPU die AES-Ni
Unterstützung hat, sollte das schon wesentlich schneller laufen!
Würde ich auch ohne Frage nehmen, allerdings gibt es nur einen Server im Rechenzentrum und die pfSense nimmt dort alle Verbindungen für den Hypervisor entgegen... Ist sicherlich nicht die allerbeste Lösung aber für meine Testumgebung reicht es...Hallo,
> Ich habe eine virtualisierte pfSense.
Das ist schon mal kontraproduktiv, denn nativ auf einer Hardware mit Intel CPU die AES-Ni
Unterstützung hat, sollte das schon wesentlich schneller laufen!
> Auf dieser pfSense läuft ein OpenVPN-Server und ein Site-to-Site-VPN
Und verrätst Du uns auch welche Verschlüsselungsstärke benutzt wird?
AES128Und verrätst Du uns auch welche Verschlüsselungsstärke benutzt wird?
> mit meinem Heimrouter. Dieses funktionierte auch einwandfrei... Bis jetzt...
Also eine VPN Verbindung ist immer eine Punkt-zu-Punkt Verbbindung und
die beiden beteiligten Seiten, sollten eben diese performant abhandeln können!
Was nützt es also wenn Du auf der einen Seite die Verbindung beschleunigst und
auf der anderen Seite ist dann nur der "Heimrouter" und der bremst dann die VPN
Verbindung wieder aus!
Es geht ja nicht nur um die Performance zum VPN-Tunnel, sondern auch um die Performance im dortigen lokalen Netz... Nicht dass ich mich vorher hätte beklagen können, aber ich dachte, man könnte es noch optimieren.Also eine VPN Verbindung ist immer eine Punkt-zu-Punkt Verbbindung und
die beiden beteiligten Seiten, sollten eben diese performant abhandeln können!
Was nützt es also wenn Du auf der einen Seite die Verbindung beschleunigst und
auf der anderen Seite ist dann nur der "Heimrouter" und der bremst dann die VPN
Verbindung wieder aus!
> Um die Performance zu steigern, habe ich die pfSense auf VirtIO umgestellt
> und die Interfaces entsprechend neu zugewiesen...
Welchen Durchsatz hast Du denn bis dato?
Ich habe den Durchsatz vorher nicht gemessen, aber es war nicht so, dass ich grund zu klagen gehabt hätte... Quasi eine vorsätzliche Mißachtung des Grundsatzes "Never change a running system"> und die Interfaces entsprechend neu zugewiesen...
Welchen Durchsatz hast Du denn bis dato?
[http://freebsdfoundation.blogspot.de/2014/08/freebsd-foundation-announces-ipsec.html FreeBSD Foundation announces IPsec
Enhancement Project]
New modes include AES-CTR and AES-GCM with hardware acceleration using Intel’s AES-NI
instructions. According to John-Mark, “on a modern 64-bit x86 CPU one core can process about
1 gigabyte per second of data” using the new AES-GCM mode.
pfSense AES-NI accelerated IPSec in 2.2
o this is, in many-respects, a "real world" test, not an artificial "in-the-lab" test.
I'm seeing between 729mbps and 891mbps throughput in the below.
Netgate C2758
OpenVPN (AES-256 TCP 116 UDP 208
OpenVPN (AES-128) TCP 120 UDP 218
Die OpenVPN-Verbindung lief ja vorher auch einwandfrei... Ich bin mir daher nicht so sicher, ob das Problem auf der Seite des VPN besteht oder doch eher in der VirtIO-Geschichte...Enhancement Project]
New modes include AES-CTR and AES-GCM with hardware acceleration using Intel’s AES-NI
instructions. According to John-Mark, “on a modern 64-bit x86 CPU one core can process about
1 gigabyte per second of data” using the new AES-GCM mode.
pfSense AES-NI accelerated IPSec in 2.2
o this is, in many-respects, a "real world" test, not an artificial "in-the-lab" test.
I'm seeing between 729mbps and 891mbps throughput in the below.
Netgate C2758
OpenVPN (AES-256 TCP 116 UDP 208
OpenVPN (AES-128) TCP 120 UDP 218
Gruß
Dobby
Dobby
Beste Grüße!
Berthold
Kann das ein MTU Problem sein ?
Hast du mal die MTU auf dem Interface etwas verringert ?
Hast du mal die MTU auf dem Interface etwas verringert ?