This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Paketfilterregeln bei v8 mit VPN und dem "Internet" Objekt

Einen schönen guten Tag,
 
wir haben hier eine sehr seltsame Entwicklung in den Packetfilterregeln der v8 festgestellt. 
In V7 ist es so, dass das "Internet"-Objekt nur für die öffentlichen IPs hinter dem "external (WAN)" Interface gelten, jedoch nicht für IPsec Regeln. 
Bsp:
 
 
Regel 1: "Internal Network"-> any -> "Internet"
Regel 2: "Internal Network" -> HTTP -> "VPN1_Network"
 
Das Resultat bei V7 ist, dass man überal ins Internet kommt, in das VPN jedoch nur über HTTP, bei anderen Verbindungen greift, wie erwartet die default Drop Regel
Das Resultat bei V8 ist, dass das "Internet"-Objekt AUCH für Verbindungen in das VPN gilt und man trotzdem überall in das VPN1 kommt.
 
Wir haben es hier intern mit einer Hardware ASG120 nach einem upgrade von v7 auf v8 und einer frisch installieren Software Astaro v8.003 und v8.1 getestet und bei allen tritt das gleiche Problem auf.


This thread was automatically locked due to age.
  • Denke das dürfte so nicht sein. Das Verhalten der V7 ist meiner Meinung nach das richtige.

    In der Definition des "Interent" Objekts steht bei V7:
    "Any" network, bound to interfaces with default gateway


    Bei V8:
    Any network restricted to uplink interfaces


    Was zeigt die ASG denn als "Bound to" an von der "Internet" Definition?

  • Was zeigt die ASG denn als "Bound to" an von der "Internet" Definition?


    Das "Internet-Objket" ist hier (v8.100) an das DSL-Interface gebunden, lässt sich (sinnvollerweise) auch nicht ändern.

    Da bei der v8 In-Kernel-IPSec zum Einsatz kommt werden die entpackten/entschlüsselten IPSec-Pakete, die am externen Interface ankommen dort wieder ins System eingespeist -- ein tcpdump auf der ppp0-Schnittstelle zeigt das sehr gut.

    Mit ausgehenden Paketen läuft es genauso. Diese sieht man einmal im Klartext auf der ppp0-Schnittstelle und dann nochmal in ESP-Paketen verpackt.

    Dadurch fällt der eigentlich interne VPN-Traffic mit in die Zuständigkeit des Internet-Objekts, und das ist irgendwie suboptimal. [:(]

    Da das ASG aber die an den SAs beteiligten Subnetze alle kennt wäre es schön, wenn Pakete die innerhalb der SAs fließen (kann man ja anhand Dst- und Src-Übereinstimmungen gut feststellen) vom "Internet Objekt" ignoriert werden würden.
  • Laut dem Astaro Support ist es kein Bug, es ist ein Feature. Ich würde es aber sehr gut finden, wenn die Tunnel wieder so wie in der V7 behandelt würden. So muss man sehr viel mehr reject Regeln machen.
  • Wau, da bin ich echt etwas erstaunt.

    Für mich ist das eher ein Bug. Und zwar ein ziemlich kritischer, wenn nach dem Update plötzlich alle VPN's voll offen sind!

    Mich würde ja interessieren was daran das "Feature" sein soll...

    Gut habe ich schon immer mein eigenes "Internet" Object gemacht und nicht das integrierte genommen. Da weiss ich wenigstens was es macht.

  • Für mich ist das eher ein Bug. Und zwar ein ziemlich kritischer, wenn nach dem Update plötzlich alle VPN's voll offen sind!


    Das sehe ich ganz genau so und ich war auch etwas erstaunt über das Verhalten der ASG, nachdem ich bemerkt habe, was da gerade so alles nicht gefiltert wird.


    Mich würde ja interessieren was daran das "Feature" sein soll...


    Ich glaube, das "Feature" soll sein, dass es sich bei der v8 nun um die Kernel-IPSec-Implementierung ist, die wesentlich robuster und performanter ist, als die Userspace-Variante. Leider gibt es dabei unter Linux aber kein eigenes IPSec-Netzwerkdevice mehr, auf dem man filtern könnte. IPSec-Flows sitzen da etwas tiefer im TCP/IP-Stack. Das benötigt beim Filtern mit Netfilter/IPTables natürlich einiges an Umdenken.


    Gut habe ich schon immer mein eigenes "Internet" Object gemacht und nicht das integrierte genommen. Da weiss ich wenigstens was es macht.


    Wie sieht denn dein eigenes "Internet-Objekt" aus? Mir fällt da eigentlich gerade keine einfache Variante ein, ein solches Netzwerkobjekt zu definieren.

    -- 
    Gruß,
    Andreas
  • Ich glaube, das "Feature" soll sein, dass es sich bei der v8 nun um die Kernel-IPSec-Implementierung ist, die wesentlich robuster und performanter ist, als die Userspace-Variante. Leider gibt es dabei unter Linux aber kein eigenes IPSec-Netzwerkdevice mehr, auf dem man filtern könnte. IPSec-Flows sitzen da etwas tiefer im TCP/IP-Stack. Das benötigt beim Filtern mit Netfilter/IPTables natürlich einiges an Umdenken.

    Na dann lieber die etwas weniger performante Userspace Variante, die auch macht was sie soll. Der Default einer Firewall muss immer ein Drop sein wenn nicht explizit ausgenommen. Und die V8 macht bei einem VPN nun plötzlich ein default allow. Das geht ja mal gar nicht!

    Wie sieht denn dein eigenes "Internet-Objekt" aus? Mir fällt da eigentlich gerade keine einfache Variante ein, ein solches Netzwerkobjekt zu definieren.

    Habe es gerade eben noch live getestet, und muss leider sagen, dass das Ergebnis das selbe ist.

    Zum Glück habe ich bis jetzt nur meine eigene Astaro zu Hause auf V8 aktualisiert. Alle produktiven Systeme werde ich nun auf V7 belassen bis dieser Bug behoben ist (was hoffentlich geschehen wird). Habe wirklich keine Lust alle VPN's (und das sind einige) manuell zu schliessen.
  • Na dann lieber die etwas weniger performante Userspace Variante, die auch macht was sie soll. Der Default einer Firewall muss immer ein Drop sein wenn nicht explizit ausgenommen. Und die V8 macht bei einem VPN nun plötzlich ein default allow. Das geht ja mal gar nicht!


    Die Kernelspace-Variante hat schon ein paar Vorteile, allerdings muss die Art und Weise, wie Traffic gefiltert wird für die Tunnel neu überdacht werden. Ich würde das lieber in der GUI und dem daraus resultierenden IPTables-Regelsatz umgesetzt sehen.

    Das mit dem "Default Drop" sehe ich ganz genauso. Es wird zwar nicht ein komplettes "Default Accept" auf den VPNs, aber eben alles, was für den Zugriff aufs Internet-Objekt erlaubt wird gilt auch automatisch für die Tunnel. Das ist schon ein heftiger Paradigmenwechsel bei der Erstellung von Filterregeln, über den man wenigstens vor dem Update informiert werden sollte. Dann kann man ja reagieren.

    Leider ist die Art und Weise, wie die Filterregelen in v8 in der Ansicht sortiert werden mehr als störend bei der ganzen Angelegenheit. Sobald man nun anfangen muss mit Drop- und Reject-Regeln zu arbeiten ist die Reihenfolge der Regeln noch wichtiger geworden. Ich bin auch etwas enttäuscht über den Ist-Zustand.


    Habe es gerade eben noch live getestet, und muss leider sagen, dass das Ergebnis das selbe ist.


    Ja, das habe ich mir schon gedacht. Mir ist nämlich auch keine Variante eingefallen, ein Netzwerk Objekt zu definieren, das die gesuchten Eigenschaften hat. Das Default Internet Object (0.0.0.0/0 gebunden an dem Uplink-Interface) ist ja schon soweit richtig. Probleme macht ein "Einspeisungspunkt" der Tunnel-Pakete.

    -- 
    Gruß,
    Andreas
  • Zum Glück habe ich bis jetzt nur meine eigene Astaro zu Hause auf V8 aktualisiert. Alle produktiven Systeme werde ich nun auf V7 belassen bis dieser Bug behoben ist (was hoffentlich geschehen wird). Habe wirklich keine Lust alle VPN's (und das sind einige) manuell zu schliessen.


    Ich glaube es wird noch nicht als Bug gesehen, aber vielleicht wird das ja noch. Wenn man wenigstens vor dem Upgrade ausdrücklich darauf hingewiesen wird dass man seine Firewallregeln anpassen muss, wäre es ja schonmal ein erster Schritt, aber die Funktionsweise des Packetfilter in V7 ist mir trotzdem lieber!
  • Es ist als Bug bestaetigt. Es ist wohl nicht so einfach, es zu fixen. Aber sie arbeiten dran.
  • Es ist als Bug bestaetigt. Es ist wohl nicht so einfach, es zu fixen. Aber sie arbeiten dran.


    Richtig. Mittlerweile hat man die Tragweite des Problems wohl erkannt. Dadurch, dass die Datenpakete vom "user space"-IPSec und vom "kernel space"-IPSec von Netfilter/IPTables komplett anders gesehen wird ist das Beheben des Problems in der Tat nicht ganz so einfach. Ich schätze mal, dass hier einiges an Umbauten in den internen Regel-Ketten passieren muss. Und das wiederum muss sehr gut getestet werden, um sich nicht ein weiteres Ei ins Nest zu legen... warten wir mal ab, was passiert.