Whistleblower

Um nochmal das ursprüngliche Thema aufzufassen - was genau sind jetzt rein technisch gesehen dafür die Gründe, dass bei der ASA der Zugriff von innen auf die ext. IP nicht funktioniert, bei Cisco Routern (entsprechende Regeln vorausgesetzt) hingegen schon? Ist das schlichtweg vom Design so vorgesehen, oder ließe sich das auch einer ASA beibringen (Sinnhaftigkeit sei mal dahingestellt)? Ansonsten Nagios und SNMP würde soweit gehen, muss mich noch näher damit beschäftigen, welche OIDs ich sinnvollerweise abfrage.

Beschränkung auf 15 User ist nicht das Thema - bei max. 5 Mitarbeitern... Server ist bereits bestellt - schadet auch nicht, Server2008 Erfahrung muss ich eh langsam sammeln :D Wusste nicht, dass es auch eine kostenloses Hyper-V Version gibt - man lernt halt nie aus ;-) ESXi wäre auch eine Option, aber vielleicht kommen wir auch komplett ohne Virtualisierung aus - ist in der Größenordnung eher überdimensioniert und verkompliziert das ganze... Wäre nur schön zu wissen, was man nimmt, wenn man Virtualisierung doch mal braucht... Wenn DATEV vorübergehend weiterbetrieben werden muss, dann heisst es einen 2003 SBS DC zu virtualisieren - das würde wenig Spass bringen... :(

Hm, verstehe ich nicht ganz - Hardware übrig... Es geht um einen neuen HP ML110, der dann mit Foundation geliefert wird - lässt sich da denn der Hyper-V überhaupt installieren? Es geht übrigens um Haufe Advolux, ist derzeit noch in Klärung, ob 64 Bit Probleme bereitet... Evtl. muss aber auch noch das alte DATEV-System für ein paar Wochen am Leben gehalten werden - das dann am liebsten in einer VM...

Hallo zusammen, könnt Ihr irgendein Produkt empfehlen, um auf einem Server 2008 R2 Foundation im kleinen Maßstab (1-2 Gäste) zu virtualisieren? Hintergrund ist, dass evtl. einige Applikationen nicht auf dem (64Bit) W2k8 laufen, und somit in einer sep. Maschine laufen müssten. Bisher habe ich immer VMWare Server 1.0.x für solche Dinge bevorzugt, aber das lässt unter 64Bit Windows-Systemen nicht mehr ohne Probleme installieren. VMWare Server 2.x läuft mir zu instabil und Hyper-V gibts in der Foundation Edition nicht... Läuft evtl. eine Version von Virtual PC oder Virtual Server oder Virtual Box problemlos unter 64Bit 2008 Foundation? Die Alternative - ESXi und darauf 2008 und weitere Gäste kommt wohl auch nicht in Frage, weil sich die Foundation Edition nicht virtualisieren lässt :(

Nichts zu machen? Auf dem alten 871er funktionierte das... Gut, dann muss ich mir eine Alternative überlegen...

Hallo, wie ist es möglich, die externe (public) IP der ASA z.B. per ICMP vom Inside-IF zu erreichen? Hintergrund: Über Nagios prüfen wir, ob die externe IP erreichbar ist, um zu sehen ob PPPoE steht. Laut Packet Tracer sollte der Traffic möglich sein, aber in der Praxis erreiche ich die IP von intern nicht. ICMP-Inspection wird nicht genutzt, sondern stattdessen ACLs mit ICMP-Gruppen. An welcher Stelle kann das ganze jetzt haken?

Wie gesagt - war eine Überlegung fürs Lab: Getestet werden sollte eine Konfig auf dem Router (871), bei dem auf dem Outside-IF eine feste pubIP konfiguriert wird, ohne dass PPPoE im Spiel ist (jedenfalls nicht auf dem 871). Einzige Lösung (meines Erachtens): sowohl auf 1751 als auch auf 871 natten, aber das bildet die reale Umgebung nicht 100% ab...

Thema hat sich eigentlich schon erledigt - ich müsste interne IPs vergeben, dann müsste ich wieder natten, und damit entspräche es nicht mehr der Umgebung, die ich aufbauen will... Hinter dem Router soll dann ein weiterer Router stehen, der auf seinem outside-IF eine öffentl. IP bekommt - wie gesagt, mit nur einer öff.IP ist das nicht zu machen und natten soll nur der zweite Router. Oder lässt sich das doch irgendwie mit privaten Adressen lösen? Also nochmal das Konstrukt: ###### #WWW# ###### | | | <--PPPoE-Dial | --->festeIP ##### #1751# kein NAT ??? ##### | int.IP:10.0.0.1 | | | "ext"IP:10.0.0.2 #### #871# NAT #### | int.IP: 192.168.123.1 | | | ###### #Clients# ###### 192.168.123.0/24 Kann man da durchsteigen? ;)

So, nachdem die ASA jetzt läuft, hab ich mir neue Aufgaben gesucht :D Ich will fürs Testlab einen guten alten 1751 missbrauchen, um aus einem Feld-Wald-und-Wiesen TDSL (mit Dialer-Einwahl) einen Business-Anschluss mit fester IP zu machen. Eine feste IP wird uns über PPPoE zugewiesen, somit müsste der Router nur PPPoE-Einwahl machen und dann die IP quasi ans zweite IF weitergeben (oder wird bereits so eingerichtet). Routing und NAT wäre somit gar nicht notwendig. Ist so ein Konstrukt überhaupt möglich ?? [uPDATE] Okay, klarer Denkfehler - ich bräuchte ja auf jeden Fall mindestens zwei öffentliche IPs dafür - richtig?

War nicht mehr viel zu ändern - nur noch inspect für PPTP aktivieren, danach lief's! Jetzt stellt sich nur noch die Frage, ob das ganze auch für einen ganzen internen Subnetz-Bereich statt für einzelne Clients machbar ist ? UPDATE: Funktioniert auch für andere Clients - die static NAT Regel konnte ich löschen static (inside,outside) tcp interface pptp IP_int_Host pptp netmask 255.255.255.255 ebenso die Regel in der outside ACL: permit gre host IP_ext Host host Eig_Pub_IP Jetzt muss ich langsam schon suchen, was auf der ASA nicht geht ;-)

Hab da ja auch auf Deine Empfehlung gehört! :)

Hatte ich schon mal grob überflogen, aber dabei noch nichts hilfreiches gesehen. Werd ich mir nochmal genauer anschauen. Einen kleinen Fehler hab ich aber schon gefunden, der allerdings keine Auswirkungen hatte. Und zwar hatte ich die ACL fürs interne Netz falsch angebunden: access-group inside_rule [b]in[/b] interface inside und hab das mal korrigiert in access-group inside_rule [b]out[/b] interface inside Jetzt machen die Regeln darin auch Sinn :D Outgoing (also access-group bla [b]in[/b] interface inside greift die Default-Regel, also permit to less secure. Jetzt ist die Frage - muss ich hier noch explizit GRE angeben?

Ist eine ASA5505-SEC-BUN-K9... Ab wann würde eine MAC-Beschränkung greifen? Die Netze, die über VPN verbunden werden sind alle noch relativ übersichtlich (je zwischen 20 und 100 Clients)... Bisher ist übrigens das Problem nicht wieder aufgetreten - werde in Kürze mal den Kiwi Syslog zur Überwachung aktivieren...

Nach und nach wächst die ASA-Konfig und deckt bald auch alle Funktionen ab, die der 871 vorher inne hatte ... :) Aktuell kämpfe ich allerdings noch damit, PPTP-Verbindungen von internen Clients nach außen zu erlauben, bzw. zu natten. Auf dem Router genügten dazu folgende Befehle: NAT-Regel: ip nat source static tcp x.x.x.0 1723 interface Dialer1 1723 ACL auf dem internen Interface: permit gre any any ACL auf dem externen Interface: permit gre host IP_ext Host host Eig_Pub_IP Die NAT-Regel konnte ich auf der ASA ähnlich umsetzen, allerdings jeweils nur für einen internen Host: static (inside,outside) tcp interface pptp IP_int_Host pptp netmask 255.255.255.255 Die GRE-ACLs habe ich auch für intern und extern eingepflegt, zählt (zumindest für intern) auch fleißig hoch. Dennoch kommt die Verbindung nicht vollständig zustande, bleibt bei "Benutzername und Kennwort werden verifiziert" hängen. Das Debug vom ASDM sagt dazu: 3 Feb 04 2010 07:34:17 305006 pubIP_externerHost regular translation creation failed for protocol 47 src inside:x.x.x.x dst outside:pubIP_externerHost Also vermutlich noch ein NAT-Problem ??

Aktuell ist bisher kein Problem mehr aufgetreten, trotzdem ich zwischenzeitlich ein 2,4GB großes File gezogen habe... Lag vermutlich tatsächlich an der Port-Konfig - fragt sich nur wer schuld war: Cisco oder 3Com... :D

Bisher hängt die ASA am gleichen Port, der jetzt allerdings auf Auto eingestellt ist. Vorher hing da ein 871 dran, dessen IF auf 100FD eingestellt war. Ich muss jetzt wohl erstmal warten, bis (ob) wieder was passiert, am besten stoß ich gleich mal einen dicken Download an :D Achso, die Struktur ist: Internet - ASA - Layer2-Switch - Layer3-Switch (Default-GW) - Clients

Hi Wordo, welches Gerät? Der Switch/Switchport? Betrifft ansonsten alle Clients... Weiss momentan nicht wo genau ich mit debug ansetzen könnte - interface? Das einzige, was mir bisher aufgefallen ist, war eine nicht passende Duplex-Einstellung: Switchport 100Full ASA-Port Auto geeinigt: 100Half ... Hab ich auch schon korrigiert (beides auto) Aber hängt sich deswegen das Interface weg?

Hm, unsere ASA 5505 blockt nach einiger Zeit (mal 2 Stunden, mal 4 Stunden, vermutlich traffic-abhängig) das interne Interface, d.h. die interne IP ist vom Netz nicht mehr zu erreichen und vom internen Interface ist das Netz nicht mehr zu erreichen. Das Interface selber kann ich aber pingen... CPU-Last (< 10%) und Memory (< 80MB) scheint kein Problem zu sein, und sonst konnte ich während des normalen Betriebes auch keine Schwierigkeiten ausmachen. Aktuell laufen darüber 11 IPSec Tunnel (4 IKE) und Traffic ist auch nicht wirklich drauf... Gibt es irgendeine Regel oder ein Feature, was sämtlichen Traffic irgendwann blockt, oder hat die ASA 'nen Schuss? :(

Hab ich gemacht - siehst Du da irgendwelche Auffälligkeiten?

sh run aaa: aaa authentication enable console LOCAL aaa authentication http console LOCAL aaa authentication serial console LOCAL aaa authentication ssh console LOCAL aaa authentication match inside_authentication inside ldap-authenticat sh run aaa-server: aaa-server ldap-authenticat protocol ldap reactivation-mode depletion deadtime 1 max-failed-attempts 1 aaa-server ldap-authenticat (inside) host x.x.x.x server-port 389 ldap-base-dn dc=domain,dc=local ldap-scope subtree ldap-naming-attribute sAMAccountName ldap-login-password * ldap-login-dn cn=administrator,cn=users,dc=domain,dc=local server-type microsoft ldap-attribute-map ActiveDirectoryMapTable aaa-server ldap-authorize protocol ldap reactivation-mode depletion deadtime 1 max-failed-attempts 1 aaa-server ldap-authorize (inside) host x.x.x.x server-port 389 ldap-base-dn dc=domain,dc=local ldap-scope subtree ldap-naming-attribute sAMAcountName ldap-login-password * ldap-login-dn cn=administrator,cn=users,dc=domain,dc=local server-type microsoft ldap-attribute-map ActiveDirectoryMapTable sh run ldap: ldap attribute-map ActiveDirectoryMapTable map-name msNPAllowDialin cVPN3000-IETF-Radius-Class map-value msNPAllowDialin FALSE NOaccess map-value msNPAllowDialin TRUE VPNaccess sh run access-list inside_authentication: access-list inside_authentication remark LDAP-Policy access-list inside_authentication extended permit tcp Mobile_Clients 255.255.255.0 any Wobei ich nicht genau weiss, ob ich "aaa-server ldap-authorize" überhaupt noch brauche, ist noch ein Überbleibsel der ersten LDAP-Konfiguration...

(Virtuelles) Netzwerkkabel gezogen... Wie würde sich das Fallback eigentlich bei Usern verhalten, die in LDAP nicht existieren? Strikt verweigern, oder auch in LOCAL nachsehen? Hintergrund: Es gibt ein paar User, die nur in einer anderen Domäne existieren (Vertrauensstellung vorhanden), wo ich aber noch nicht weiß, ob die über LDAP mit erfasst werden (in der Testumgebung habe ich nur eine Domäne). Diese User ziehen kurzfristig in die neue Domäne um, somit muss für einen Übergangszeitraum eine Lösung gefunden werden. Notfalls muss ich sonst eine sep. Policy für diese User anlegen.

Ein kleines Problem besteht noch, und zwar erfolgt kein Fallback auf die Auth. via LOCAL users, wenn der LDAP-Server nicht erreichbar ist. In der Tunnel-Group ist "use LOCAL if server group fails" eingerichtet, dennoch versucht er immer eine Abfrage über LDAP, und greift nicht auf die LOCAL users zurück. Timeout und retry habe ich schon runtergesetzt (1 Minute, 1 Retry)... :confused:

Das hab ich auch schon zahlreich gelesen - wobei wohl häuptsichlich die Fehlersuche bei LDAP schwieriger ist. Nur bisher wird kein Radius genutzt, und das gute ist: LDAP funzt jetzt !! :D Ich hatte erst versucht, eine bestehende Gruppe mit lokaler Auth. auf LDAP umzustellen, und da wahrscheinlich den Fehler im Detail nicht gefunden. Habe die jetzt gelöscht und anschließend neu für LDAP erstellt, getestet und alles läuft! :) Für alle, die auch auf die schnelle LDAP mit der ASA nutzen wollen, hier die fehlenden Puzzle-Teile, damit man den VPN-Zugriff für die einzelnen Benutzer regeln kann. Im größeren Umfeld ist sicher der Einsatz von Radius empfehlenswert, aber im kleinen Bereich (hier sind das ca. nur 20 Nutzer), reicht auch die Einrichtung über LDAP.

Bin schon mal einen Schritt weiter - habe jetzt die richtigen Custom Names gefunden und eingetragen - der Test für Authorization und Authentication lief jetzt erfolgreich :) Erster Test mit VPN Client klappte noch nicht - hier hatte ich auch noch Änderungen an den Tunnel Groups vergessen. Danach hatte der Client sich erstmal aufgehängt und zog einen Rechner-Reboot nach sich :rolleyes: Danke erstmal für die Debug-Tipps, werd Euch auf dem Laufenden halten!

Hi, ich versuche derzeit nach der Anleitung "Configuring an LDAP AAA Server" von Cisco eine Verbindung zwischen ASA und LDAP auf Server2003 DC zu bewerkstelligen. Ziel soll es sein, dass sich Remote-User (IPSec VPN Client) über Ihre Windows-Credentials an der ASA authentifizieren, so dass keine separate (lokale) User-Datenbank auf der ASA gepflegt werden muss. Mir ist allerdings schon nicht klar, welche Attribute ich genau in der LDAP Attribute Map einpflegen muss... :confused: Hat hier jemand so eine Lösung am Laufen und kann mal ein paar Hinweise zur Konfiguration geben? Momentan ist das ganze noch eine Testumgebung mit einem frischen ADS, so dass es noch recht übersichtlich bei der Fehlersuche ist :D Wenn andere Lösungen z.B. über Radius o.ä. besser/sicherer/einfacher einzurichten sind, nehme ich auch da gerne Vorschläge an, hab bisher nur kein Radius hier am laufen... UPDATE: Einen ersten Fehler habe ich bereits gefunden: LDAP über SSL kann ich derzeit nicht verwenden, da der DC keine Zertifizierungsstelle findet (Event-ID 36872). Also auf der ASA LDAP über SSL deaktiviert. Dennoch bekomme ich beim Testen der LDAP server group für Authorization und auch Authentication den Fehler: ERROR: Authorization Server not responding: AAA server has been removed Wie kann ich den Fehler näher eingrenzen? Erreichbar (ICMP) ist der DC von der ASA. In den Events des DC sehe ich leider keine Zugriffsversuche...