• Servus,

    geplant ist ein IPSEC Tunnel zwischen 2 pfS. Die beiden Subnetze dahinter sollen voll erreichbar sein, ein Windows AD mit je einem DC in jedem Netz und globaler Erreichbarkeit ist geplant.

    Funzt in meiner Testumgebung auch alles super.

    Nun komme ich an den Punkt wegen NAT IPSEC nicht nutzen zu können (daran hab ich vorher nicht gedacht…) und muss wohl auf OpenVPN umsteigen  ::)

    Wie sind die Erfahrungen mit OpenVPN? Funzt das gleichwertig mit IPSEC in o.g. Konfiguration? Wie siehts mit der Sicherheit aus?

    Danke!

    Gruß,

    Thorsten


  • IMO ist OpenVPN rein von der Funktionalität und Bedienung her besser als IPSEC.
    (Wobei die pfSense viel tut um IPSEC bedienbarer zu machen).
    Aber gegenüberstellung Funktionalität IPSEC vs. OpenVPN auf der pfSense, gewinnt OpenVPN klar.

    Rein von der Sicherheit sind beide "sicher", so sicher eine Technologie halt ist. Unsicherheiten kommen mehr vom Netzwerk Design als von der darunterliegenden Technik.

    Schlussendlich ist es wohl persönliche Präferenz was man einsetzt.


  • Hi,

    ich fand die IPSEC-Konfig denkbar einfach. In 5 Minuten war der Tunnel online und läuft perfekt. Mit OpenVPN stell ich mich tatsächlich etwas an  ;D

    Mir ist die Tunnelfunktion mit OpenVPN bei static Site2Site aber auch noch nicht so ganz klar. Bei IPSEC konfigurier ich ja auf beiden pfS jeweils Phase 1 und 2, jeweils auch mit dem anderen Remotesubnet, bei OpenVPN aber nur eine einfache Client-Server- Beziehung.

    Ist das unterm Strich nicht was Anderes?

    VPN ist so gar nicht meine tägliche Baustelle, daher mangelts da an dem ein oder anderen Wissen  ;)

    Gruß,

    Thorsten


  • Ja bei OpenVPN erzeugt man eine einfach Verbindung Client–>Server.
    Die Verbindung selbst besteht aus einem route-baren Netzwerk.

    Die "Einfachheit" von OpenVPN kommt daher, dass es wie ein virtuelles Kabel betrachtet werden kann.
    Für das System besteht kein Unterschied ob ein echtes physikalisches Interface oder ein virtuelles OpenVPN interface im Einsatz ist.
    Es kann einfach gerouted werden.
    --> OpenVPN ist eine Art "virtueller Layer 1" und kann auch Layer1-mässig behandelt werden.

    Hingegen muss bei IPSEC der traffic auf Treiberebene abgefangen und weiterverarbeitet werden.
    Daher kann man ja auch nicht routen oder NAT betreiben über IPSEC.
    Es sind einfach zwei ganz andere Ansätze.


  • Super, danke für die Infos.

    Bin mal gespannt obs so tut, wie ich mir da vorstelle  ;D

    Gruß,

    Thorsten

  • LAYER 8 Moderator

    Also dass man nicht routen bzw. NAT betreiben kann mit IPSec wage ich doch arg zu bezweifeln - wäre das der Fall wäre bspw. Cisco schon lange untergegangen. ;)

    NAT geht, allerdings müssen die Geräte entweder mit entsprechenden PortForwardings konfiguriert werden oder IPSEC mit NAT-T eingesetzt werden. Und warum soll man durch einen IPSEC Tunnel nicht routen können confused?

    Sorry Gevatter Frosch, das kann ich gerade nicht so nachvollziehen. Da ich aktuell gerade nicht viel mit dem IPSEC der Sense baue, mag das die Sense betreffen aber IPSEC allgemein sicher nicht :)

    Zum allgemeinen Tonus aber würde ich unserem grünen Freund dennoch zustimmen, dass das was Thorsten versucht zu erreichen, sich mit OpenVPN realisieren lässt und ggf. sogar einfacher als IPSec :) Und tpf: warum es so "einfach" anmutet mit OpenVPN ist auch, dass es sich bei jenem um eine SSL-basierende VPN Lösung handelt während IPSEC ja ein völlig eigenes Protokoll inkl. Crypto mitbringt. Auf entsprechender Hardware kann dann auch IPSEC schneller sein als OpenVPN, da es einige Hardware gibt, die 3DES oder AES in Hardware de/codieren können, was den Prozessor entlastet. Bei OpenVPN ist mir gerade keine Hardwarebeschleunigung geläufig die das tut :)

    Grüßend
    Grey


  • @Grey:

    Also dass man nicht routen bzw. NAT betreiben kann mit IPSec wage ich doch arg zu bezweifeln

    Huhu,

    wenn das NAT ne Passtroughfunktion hat, wie es denn jeder billige Hiemnetzrouter anbietet, ist das alles auch kein Thema. Nur "unser" NAT ist darauf nicht konfiguriert und daran wird auch nicht rumgespielt. Da hängen über 10.000 Maschinen dran  ;D

    Momentan bin ich mit anderen Dingen beschäftigt und kam bei OpenVPN nicht weiter, muss das in den nächsten Wochen aber wieder in Angriff nehmen.

    Gruß,

    Thorsten


  • @Grey:

    Also dass man nicht routen bzw. NAT betreiben kann mit IPSec wage ich doch arg zu bezweifeln - wäre das der Fall wäre bspw. Cisco schon lange untergegangen. ;)

    NAT geht, allerdings müssen die Geräte entweder mit entsprechenden PortForwardings konfiguriert werden oder IPSEC mit NAT-T eingesetzt werden. Und warum soll man durch einen IPSEC Tunnel nicht routen können confused?

    Sorry Gevatter Frosch, das kann ich gerade nicht so nachvollziehen. Da ich aktuell gerade nicht viel mit dem IPSEC der Sense baue, mag das die Sense betreffen aber IPSEC allgemein sicher nicht :)

    Zum allgemeinen Tonus aber würde ich unserem grünen Freund dennoch zustimmen, dass das was Thorsten versucht zu erreichen, sich mit OpenVPN realisieren lässt und ggf. sogar einfacher als IPSec :) Und tpf: warum es so "einfach" anmutet mit OpenVPN ist auch, dass es sich bei jenem um eine SSL-basierende VPN Lösung handelt während IPSEC ja ein völlig eigenes Protokoll inkl. Crypto mitbringt. Auf entsprechender Hardware kann dann auch IPSEC schneller sein als OpenVPN, da es einige Hardware gibt, die 3DES oder AES in Hardware de/codieren können, was den Prozessor entlastet. Bei OpenVPN ist mir gerade keine Hardwarebeschleunigung geläufig die das tut :)

    Grüßend
    Grey

    Hehe :)
    Klar ist es möglich mit IPSEC zu NATen, einfach nicht mit pfSense.
    Ich habe hier nur bezüglich der pfSense eine Aussage gemacht.
    IPSEC ist auch in vielen Bereichen klar das VPN der Wahl da es der weitest verbreitete VPN Standard ist und somit die meisten Geräte es auch unterstützen.
    IMO wenn es sich jedoch vermeiden lässt, setze ich es nicht ein.

    Bezüglich dem nicht routen können:
    Traffic welcher eine Destination hat, die auf der anderen Seite eines IPSEC Tunnels liegt, wird nicht von der routing Tabelle verarbeitet, sondern direkt über den Tunnel geschleust.
    Es ist auch nicht möglich manuell einen Gateway auf der anderen Seite eines IPSEC Tunnels einzurichten und dann Traffic an den zu schicken mit Policy-Routing-Regeln. Schlichtwegs, weil der Traffic nicht den Kriterien entspricht nach welchen entschieden wird ob Traffic in den Tunnel geleitet werden muss oder nicht.
    Mit der Version 2.0 der pfSense ist es jetzt allerdings möglich mehrere Phasen 2 zu einem Tunnel hinzuzufügen und somit mehrere destinations angeben zu können welche umgeleitet werden.
    Mit 1.2.x musst man bis anhin für jedes zusätzliche subnet welches in den Tunnel geleitet werden sollte einen zusätzlichen Tunnel konfigurieren.

    OpenVPN kann genau so von den Krypto-beschleunigern gebrauch machen welche auch IPSEC beschleunigen.
    Normalerweise kann das aktiviert werden indem mal in den custom options den Befehl: "engine cryptodev;" hinzufügt oder ähnlich.
    Generell kann all die Hardware verwendet werden welche von der SSL Library verwendet werden kann.

  • LAYER 8 Moderator

    Aaah danke der Aufklärung, my bad. Wie gesagt ist etwas her dass ich mit der Sense IPSEC eingesetzt habe :)

    Und danke für die Info bezüglich der Cryptos, das würde aber voraussetzen, dass man OpenVPN auch mit entsprechenden CEs benutzt also 3DES oder AES, der Standard mit Bluefish etc. dürfte von der Crypto Hardware ja kaum profitieren oder täusche ich mich da?


  • Servus,

    ich habe es nun nochmal mit IPSEC versucht und siehe da: Der Tunnel steht.

    Problem: Mir ist nicht ganz klar wie das funzt?

    ESP kann maximal auf der linken Seite zur pfS1 geleitet werden, auf der rechten Seite erlaubt das NAT nur die angebeben Ports. Der Tunnel läuft auch nur wenn links ESP verfügbar ist, die Gegenprobe habe ich schon gemacht.

    Auf beiden pfS ist NAT-T-Option im IPSEC aktiviert.

    Müsste nicht auf beiden Seiten ESP verfügbar sein?