Re: Eierlegende FW/Router-Lösung gesucht

moin,

meiner erfahrung nach kommen *doch* immer wieder irgendwelche
anforderungen, die man einbauen muss. bei den ciscobüchsen sind wir
doch immer wieder ertaunt, welche beschränkungen es da gibt (die dann
auch der cisco-support nicht beheben kann).

Welche Anforderungen? Ich kenne zwar einige Einschraenkungen bei der
GUI-Konfiguration (anscheinend unterstuetzt das GUI keine "group-objects"
in "group-objects", per Kommandozeile kann man so etwas aber durchaus
konfigurieren ...

z. b. das mit den gruppen.

z.b. ist es ein elendes geklicke und / oder copy-and-paste im CLI, bis
man ein paar anständige regeln für einen server in der dmz
zusammengebastelt hat. eine vernünftige policy habe ich auf der ASA
auch noch nicht entdeckt, es muss explizit immer wieder alles gesperrt
werden für einzelne dienste und / oder rechner.

natten mehrerer hosts über eine adresse mit womöglich noch selektivem
umleiten einzelner ports, wie wir es bei den iptables-lösungen machen,
geht auch nicht - eines unserer netzwerke, unter netfilter vorher nach
aussen noch recht schlank und überschaubaren regeln ausgestattet, ist
mittlerweile ein - aus meiner ganz subjektiven sicht! - wust an
regelwerk und konfigurationen. und sowohl GUI wie CLI-ACL sind
gaaaanz, ganz lang, wo es vorher weniger regelsätze taten. ich muss
schon sagen, dass gerade netfilter mit diversen erweiterungen
mittlerweile unglaublich flexibel und leistungsfähig ist; das war zu
ipfwadmin-zeiten noch anders ... ;-)

- gleich zu beginn des betriebs der ASAs gab es dann probleme mit dem
mailempfang, weil die ASAs - trotz gegenteiliger aussage unseres cisco-
resellers bzw. cisco-admins - den smtp-dialog nicht komplett
durchgelassen haben. gut, dass wir auf der lauer waren, weil kollegen
aus der mailserver-group uns vorgewarnt hatten, so hielt sich der
mailausfall in grenzen.

- ein abgleich der intrusion detection mit unseren servern (web, mail,
ssh, ftp) geht jetzt auch nicht mehr, aber das war vorher klar; also
mussten wir die server wiederum besser abschotten.

- der dhcp der ASAs versagt bei supernetting kläglich. ergebnis:
entweder kleinere netze oder doch wieder einen oder zwei besondere
server fürs DHCP. ich kenne lösungen - die wir auch betreuen -, bei
denen das alles sauber auf geclusterten firewall-lösungen liegt, und
das seit jahren stabil und performant, wie es auf neudeutsch so schön
heißt.

- da die ASAs es auch nicht schaffen bzw. der cisco-admin uns davon
abgeraten hat, getrennte regelsätze für interne und externe
namensauflösung zu machen, müssen wir seit der umstellung einen
weiteren DNS-server betreiben - klasse ... vorher wurden die anfragen
intern auf der firewall umgebogen und wir mussten - zugegebenermassen
- doppelte regelsätze erstellen. jetzt haben wir einen server mehr
(bzw. im falle von clustering sogar zwei) und müssen eben dort alles
doppelt eintragen.

Trotz Erfahrungen mit beidem komme ich zum gegenteiligen Schluss. Fehlt
dir vielleicht Erfahrung mit Cisco PIX und Cisco ASA?

so ist es. im umkehrschluss könnte ich natürlich sagen: wer cisco für
stabiler/performanter/einfacher als netfilter und co. hält, hat
womöglich auch nicht genug erfahrungen im OpenSource-Bereich ;-)
immerhin haben wir einen ganz guten vergleich der aktuellen systeme,
bei der ASA sogar mit einem recht aktuellen IOS. möglicherweise haben
wir da aber auch entweder einen schlechten cisco-admin - wir betreuen
die dinger im alltagsbetrieb, aber fürs eingemachte müssen wir uns
immer an einen externen admin wenden - oder es fehlt noch an schulung
und erfahrung.

da der beginn des threads ja aber die frage nach der eierlegenden
wollmilchsau war - die es kaum geben dürfte -, ist es sicher wichtig
zu wissen, dass eine cisco-lösung auch nicht ohne einschränkungen ist;
nach unseren erfahrungen und dem support nach zu schliessen, den wir
eingekauft haben - und wir haben für die dinger plus support schon
nicht wenig geld bezahlt.

eine linux-lösung lässt sich meines erachtens besser vorbereiten und
testen - nimm einfach einen alten 486er und schliess zwei, drei
netzwerkkarten an und leg los -

ganz grob würde ich sagen: für eine lösung a la cisco oder anderen
musst du erstens trotzdem wissen, was du tust,

Das musst du bei *jeder* Firewallkonfiguration, wenn etwas brauchbares
dabei herauskommen soll.

sag-ich-doch! ich habe es aber schon erlebt, dass proprietäre lösungen
(nicht nur Cisco!) nach dem motto verkauft werden: "da können sie
alles mal eben selber machen!" - graus!!


Welche Grenzen? Nenne doch mal eine Grenze, an die du bereits im
produktiven Betrieb gestossen bist. Was wolltest du konfigurieren,
was mit der ASA nicht ging, mit Linux und iptables aber schon?

siehe oben. und ausserdem: wir benötigen appletalk-zone-routing, und
das schaffen die ciscos auch nicht. also haben wir doch wieder einen
weiteren server aufstellen müssen ...
es ist eben nicht nur iptables, es ist die komplettlösung, die an der
linuxlösung gefällt. Clientloes VPN hatten wir schon, als sie bei
cisco noch nicht mal wussten, wie man das wort buchstabiert ...

unsere serverstruktur ist aufgeblähter als vorher, aber da haben wir
uns auch schlecht beraten lassen bzw. die chefetage hat eine abneigung
gegen OpenSource ( = wie ich mal irgendwo gelesen habe, ist das beste
Linuxadminteam machtlos gegen den schlechtesten Ciscoadmin, weil der
den schlipsfaktor mitbringt ;-)).

mit den lösungen im OpenSoure-bereich sind wir flexibler bei erheblich
geringeren anschaffungskosten und vergleichbarer stabilität bzw.
wartung.

Wie kommst du auf "flexibler"?

s. o.


Warum nicht? Wo liegen die Probleme?

s.o.

neuerdings haben wir im Tunnel immer netzausfälle. das erste problem
betrifft das initiieren des tunnels, der über nacht abgebaut wird,
sowohl unter Pix wie ASA; das haben wir mit den IPSec/OpenVPN-lösungen
nicht.

es ist gerade bei OpenVPN unglaublich, wie stabil und leistungsfähig
die tunnel sind. und während der cisco-vpn-client z.b. auf unseren
zahlreichen Macs immer wieder probleme macht, funktioniert der OpenVPN-
GUI-client auf den dingern problemlos. plus der flexibilität im open-
source-bereich, sich "mal eben schnell" ( = ok, du weisst natürlich,
was "mal eben schnell" im it-bereich heissen kann.
das aktuelle problem sind teilweise minutenlange kompletausfälle des
VPN. wir suchen noch ...


gruss


Marcus Liwi
.

Relevant Pages