Erfahrungen mit ISA2004?

[Slavewarrior]

Hi Leutz,

ich habe von einem Kunden die Frage gestellt bekommen ob es möglich ist VoIP (sipgate.de) über einen Microsoft ISA2004 zu handeln.
Hat da jemand evtl. Erfahrungsberichte bzw. was muß man dort wie und wo einstellen??
Danke für eure Hilfe!!

 

[CaptainCrunch]

Ist das ISA-Zeugs nicht eigentlich nur ein etwas aufgebohrter Proxy (der bei uns ganz schnell wieder durch nen Squid ersetzt wurde )?

 

[Slavewarrior]

Nein, ganz im Gegenteil. Wir haben schon eine Menge gute Erfahrungen im Bereich Contentfiltering, Proxy, Firewall etc. mit dem Teil gemacht. Ist zwar richtig teuer, aber ich habe bis dato noch keine Klagen gehört. Stabil ist es auch, was man ja bei manchen anderen Produkten nicht sagen kann :lol:

 

[schakal2k]

Da ich gerade dabei bin, meinen Windows Small Business Server 2003 Premium einzurichten und nun auch endlich das SP1 eingetroffen ist, kann ich das demnächst mal testen...

Aber genau die Frage wollte ich auch hier stellen...

Sobald ich neue Erkenntnisse habe, melde ich mich wieder...

Nochmal zum ISA2004:

Was ich bisher darüber gelesen habe, klang wirklich nicht schlecht...

VPN kann er auch. Sogar HTTPS kann er entschlüsseln und wieder verschlüsseln...

Hast du vielleicht schonmal versucht, einfach die Ports weiter zu leiten?

 

[Tombola]

Hi,

in unserer Firma nutzen wir den ISA-Server 2000 und sind sehr zufrieden.

Ich habe VPN zur Fernwartung eingerichtet.

Gute Informationen bekommst du hier.

Gruß Thomas

 

[schakal2k]

Auch wenn das hier ein wenig OT ist, aber kann es sein, dass der ISA recht viel Arbeitsspeicher frisst?

 

[Wildi]

ISA 2004 und VoIP funkioniert prima. Beim 2000'er ISA wäre ich vorsichtig. Der kann z.B. kein uPnP usw.

Machst Du einfach eine Serververöffentlichungsregel
Quelle: Extern
Ziel: Das SIP Telefon (bzw. das SIP Gateway im LAN)

Musst halt dann nur noch ne eigene Protokollregel dafür basteln.
5060/UDP Eingehend und 5004/UDP Eingehend - fertig.

Hab ich bei mir hier auch. Grandstream Tele's, Sipgate Konten, ISA 2004

UND WEIL ICH'S GERADE LESE:
ISA nur ein Proxy? Waaaaaaaaah - mir rollts die Zehnägel auf.
Der ISA ist einer der besten Enterprise Firewalls auf'm Markt. Den kannst Du mit ner CISCO PIXX gleichsetzen. Wenn Du ne reine MS Domain hast, ist der ISA sogar um einiges vorteiliger.

ISA und viele Ressourcen?
Das kommt darauf an, wieviel daran hängt. Also bis ca. 1000 Clients reicht ein popeliger Celeron 1,8 mit 256MB (besser 512MB) locker aus. Haben einige Kunden von mir so. Für den Cache reichen ca. 2GB für 1000User

EDIT:

Auch wenn es möglich ist, den ISA auf jeden nur erdenklichen Server zu installieren (hier SBS Premium) würde ich dringend davon abraten.
Der ISA (wie jede andere softwarebasierende Firewall) sollte UNBEDINGT (!!!) auf einer alleinstehenden Kiste laufen. Zu viele Dienste wären anderenfalls angreifbar.

Bei nem Spiel-, Test- und Wald-&Wiesenserver ist das zwar wurscht. Aber sobald sensible Daten drauf sind oder der ISA wirklich was sichern soll, würde ich das auf keinen Fall machen

 

[Slavewarrior]

@Wildi

Kannst du denn evtl. genauer erklären wie die Regeln genau aussehen sollen? Ich meine die Ports/Regeln erstellen ist kein Ding, aber ob nun 5060 nur empfangen ist oder senden/empfangen oder sonst wie, wäre mir bis hierhin noch nicht klar.
Besten Dank!

Thomas

 

[CaptainCrunch]

<Polemie>

Aber sobald sensible Daten drauf sind oder der ISA wirklich was sichern soll, würde ich das auf keinen Fall machen

Wenn's um sensible Daten geht, würde ich einem MS-Produkt erst gar nicht über den Weg trauen.
</Polemie>

 

[Wildi]

ISA2004

Guten Morgen,

nun ja, ich kenne ja nicht Deine Ausgangssituation. Also, was ist schon offen, wer darf was - wohin? usw.

Fangen wir mal von Grund auf an. Wenn Du den ISA installierst, kann der ja zunächst gar nix. Er lässt weder was raus, noch was rein. Selbst der ISA Server als Rechner kann niergends zugreifen. Das Einzige was geht ist die Domänenanmeldung. Das ist aber wirklich das Einzige was der ISA Server nach Installation kann.

OK, jetzt soll es natürlich so sein dass die Clients im LAN einen Internetzugriff erhalten (evtl. der ISA Server selbst auch).

Dazu erstellt man eine Zugriffsregel:
Rechte Maustaste auf Firewallrichtlinie -> Neu -> Zugriffsregel
Regelname: Egal (z.B. Internetzugriff für alle)
Regelbedingung: Zulassen

Protokolle:
Jetzt kommt es drauf an, was Du alles zulassen willst (Standard ist: Gesamter ausgehender Datenverkehr). Dann lässt der ISA jede nur erdenkliche Clientanfrage nach außen und die Antworten kommen natürlich zurück. Also HTTP, HTTPS, FTP, DNS, POP, SMTP, SIP usw. Einfach alle Protokolle die möglich sind.

Quelle:
Betrifft die internen Clients. Also welche Rechner und Hosts dürfen überhaupt. Ich habe in meiner Testumgebung gewählt: Intern und Lokaler Host. (Achtung: Intern bedeutet alle internen Clients die über Netzwerk auf den ISA zugreifen, nicht aber der ISA selbst. Willst Du den auch musst Du Lokaler Host auch auswählen)

Ziel:
Wo dürfen die Clients denn hin? Also Extern

Wer darf:
Das ist das schöne am ISA. Er verwendet die AD Benutzer und man kann nach Benutzern bestimmen (Hier: Alle Benutzer). Wenn die eigene Domäne ein reine Windows Domäne ist, ist dass der große Vorteil von ISA. Bei ner PIX o.dergleichen müsste man mit nem RADIUS arbeiten, damit sowas anständig geht

Somit ist der Zugriff von Innen nach Außen für Alle mit allen Möglichkeiten gewährleistet.
Wenn es bereits eine derartige Regel gibt, diese allerdings im Protokoll eingeschränkt ist oder nur bestimmte Benutzer dürfen, kann es mit dem SIP'en zu Problemen kommen.
Grund 1: Je nach Telefon benötigt man bestimmte Protokolle/Ports für das Teil, damit es geht.
Grund 2: Da das Telefon ja kein Mitglied einer MS Domäne ist, kann es zu Problemen kommen, wenn die Zugriffsregel auf Benutzer begrenzt ist, da das Telefon ja so gesehen kein Benutzer sondern eher ein reiner Host ist.

Abhilfe:
Du erzeugst eine neue Zugriffsregel. Genau wie oben beschrieben (Protokoll: Alles) und begrenzt die Quelle auf die IP's die die Telefone haben. Bei Benutzer dann natürlich Alle Benutzer.

Diese neue Zugriffsregel ist dann Coexistent mit der bereits bestehenden Regel.

DAS WAR STEP 1, DAMIT DER VERKEHR VON INNEN NACH AUSSEN GEHT!!!

Weiter im Text. Jetzt geht es um das Incomming (Signalisierung und Ruf)
Dafür brauchen wir ne Serververöffentlichungsregel:

Rechte Maustaste auf Firewallrichtlinie -> Neu -> Serververöffentlichungsregel

Name: z.B. VoIP Phone 1 (Chef)
Server IP: IP Adresse des Telefons
Protokoll: Hier muss eine neue Protokollregel definiert werden (Die gibt es noch nicht als Template)
Also -> Neu
Name: z.B. VoIP 1 Server
Primäre Verbindung -> Neu
Typ: Vermutlich UDP (die meisten SIP Telefone)
Richtung: Empfangen
Port von: 5060 bis: 5060
OK -> Neu
Typ: Vermutlich UDP (die meisten SIP Telefone)
Richtung: Empfangen
Port von: 5004 bis: 5004
OK
Abhören: Extern
Fertig

Die Ports 5060 und 5004 sind Standardports für das 1. Telefon. Sind die an Deinem Telefon anders, dann natürlich die Ports eintragen.
Hast Du ein 2., 3., X. Telefon musst Du Dir natürlich so viele Serververöffentlichungen erstellen und Protokollregeln, wie Du Telefone hast. Natürlich dann mit je unterschiedlichen Ports

Sonst noch was? Das macht dann 3 Geld 50. Zu überweisen auf mein virtuelles Konto

Und wer kann mir nun bei meinem Problem helfen? ->
http://www.ip-phone-forum.de/forum/viewtopic.php?t=19166

 

[Wildi]

<Polemie>

Aber sobald sensible Daten drauf sind oder der ISA wirklich was sichern soll, würde ich das auf keinen Fall machen

Wenn's um sensible Daten geht, würde ich einem MS-Produkt erst gar nicht über den Weg trauen.
</Polemie>

Ohne Kommentar :roll:

 

[Slavewarrior]

@ Wildi,

Danke erst einmal für Deine Ausführung. Schön ausführlich - das gefällt mir
Ich habe das gerade mal ausgetestet, mußte aber feststellen das mein CISCO erst, laut des Trafficprotokolls, via Port 5060 senden möchte als zu empfangen. Verweigerte Verbindung kam als Meldung raus. Müßte man nicht erst über 5060 senden um sich anzumelden??
Stehe im Moment vor einem Rätsel

Greetz
Thomas

 

[Wildi]

Senden/Empfangen

Ich glaube Du verwechselst da ein bissi was

Zugriffsregel bedeutet:
Senden von innen. Antwort kommt egal auf welchen Port zurück. Auf jedenfall wird die Anfrage beantwortet.

Serververöffentlichungsregel bedeutet:
Senden von außen. Die Antwort kommt über den Port zuzrück über den die Anfrage kam.

Soll heißen, je nachdem wer Anfrägt (einer von Innen = Zugriffsregel oder einer von außen = Serververöffentlichungsregel), beinflusst die Regeln untereinander nicht.

Wenn Du also die Zugriffsregel auf 'Allen Verkehr' setzt kann das Telefon Anfragen über jeden nur erdenklichen Port machen. Gleichgültig wie Deine Serververöffentlichungsregel aussieht.
Mit Zugriffsregel aller Verkehr hast Du ja schon den Weg geebnet.
Wenn Dich nun jemand anruft kommt die Anfrage ja von draußen (Signalisierung), daher die Serververöffentlichungsregel (Anfrage von aussen)

Kleiner Tip und ich will DIch dabei nicht persönlich angreifen:
Bevor Du das Spielchen an einem heißen Produktivnetz machst, mach Dich bitte erst mit den Grundlagen des ISA vertraut.
Ein falsches, unüberlegtes Einstellen kann gefährliche Auswirkungen haben. Es geht in 1. Linie um eine Firewall die ein sicheres Netz vor einem unsicheren Netz schützen soll.

 

[Slavewarrior]

@ Wildi,

kein Problem, lasse mich nicht persönlich angreifen 8)
Alles klappt jetzt vom feinsten. Habe natürlich vergessen dem Telefon den Zugang nach extern zu geben - logisch das keine Verbindung enstehen kann :wink:
Außer Port 5060 und 5004 (beides UDP) habe ich auch noch 16384-16388 (UDP) mit in die Serverregel eingebunden, denn sonst war mein CISCO übelst am spinnen.
Also: big THX an Wildi!!

P.S.: im Produktivnetz arbeite ich erst dann, wenn ich die Kiste begriffen habe, keine Sorge

 

[Slavewarrior]

@Wildi,

kannst Du mir denn auch noch einmal erklären bzw. die genauen Regeln nennen, die ich für TFTP auf dem ISA brauche. Das es Port 69 ist, weiß ich, und das man sowas nicht auf einen ISA intern auf dem selben Rechner laufen soll, aber als Test ist das ok, denke ich.
Besten Dank!

Thomas

 

[Wildi]

Die Lösung ist, dem (T)FTP Protokoll auch den Schreibzugriff zu erlauben.

Wähle die Eigenschaften der Regel in der du (T)FTP freigibst. Dort klickst du unter dem Reiter Protokolle auf den Schalter Filterung und wählst dann (T)FTP konfigurieren.
Hier siehst du gleich, dass (T)FTP nur lesend konfiguriert ist. Wähle den Haken ab und dein Problem ist gelöst.