Paketfilterregeln bei v8 mit VPN und dem "Internet" Objekt

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

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