hegl

Nutzen die Clients denn auch IPSec over UDP, wenn Du nat-traversal konfigurierst? Ich hatte mal das Problem in einer Testumgebung, dass trotz nat-traversal kein IPSec over UDP lief - weiß der Geier warum :mad: Allerdings war das noch unter 6.3.x

Auf welchen Provider spielst Du an?

Laut CISCO ab 5510 mit Security Plus License Cisco ASA 5500 Series Release Notes, Version 8.0* [Cisco ASA 5500 Series Adaptive Security Appliances] - Cisco Systems

Tja, sowas nennt man "Lehrgeld bezahlen" ...

Na supi, und genau für dieses Szenario habe ich die ASA´s gekauft. Mal schaun, wie mein Chef darauf reagiert :mad: Das passiert, wenn man sein eigenr Key-Account-Manager ist...

Welches Buch meinst Du? Ich habe das ASA Firewall Handbook Vers.7 von ciscopress und die Original Cisco Schulungsunterlagen und dort finde ich nichts. Kannst Du mir auf die Sprünge helfen?

Wo hast Du diese Info her? Bin gerade auf dem besten Wege zwei ASA´s mit active/active und meheren VPN´s in Betrieb zu nehmen.

Ich gehe nach Hause - jetzt nimmt die Kiste den Befehl :confused:

Nö ....

Habe gerade die 8-er Version installiert und wollte nun alte images/configs auf disk0 löschen. Bei 7.x ging das mit clear disk0:filename , in der 8-er kennt die ASA diesen Befehl aber nicht mehr. Weiß jemand wie´s geht?

Wir können doch hier nur alle spekulieren, rufe Deinen Provider an und kläre die Sache! Ein Netz hast Du ja auf alle Fälle zugewiesen bekommen, stellt sich nur die Frage, ob der Provider auch alle IP´s durchlässt - also ruf einfach an und Du weißt Bescheid!

erledigt

Hast gewonnen ;)

Ich hab´s bis jetzt auch nur einmal im Kurs gemacht. Bei meiner config bin ich noch nicht so weit und deshalb auch nicht so im Thema. Mit der 5510 Security Plus hast Du recht, solange Du die Version 8 einsetzt. Mit 7.X gabs nur active/standby.

Active/Active geht meines Wissens nach erst mit der 5520 und dann aber auch "nur" mit zweien. (wie soll das mit 4 Stück gehen???) Die ASA kann trunken und die Failover-Scenario kannst Du komplett über VLANs abwickeln. Site-to-Site geht am einfachsten über den ADSM. Registrieren, wofür? 3DES/AES ist enthalten. ASA Series

Fehler gefunden: ich muss für die NAT-Adresse die ACL fürs outside interface konfigurieren access-list out1 extended permit tcp host 222.222.222.222 host BBB eq 80

Es sollte doch egal sein, an welches interface ich den traffic von inside nach outside binde. Ob ich nun die Regel access-group out1 out interface outside oder access-group out1 in interace inside definiere, sollte doch gleich sein. Oder sehe ich das falsch? Selbst wenn ich die ACL für den host AAA ans outside binde, erhalte ich o.g. error!

Ich sehe irgendwie den Wald vor lauter Bäume nicht mehr. Hier ein Auszug aus meiner config einer ASA Vers.7.2.2: name 111.111.111.111 BBB object-group network TEST network-object host AAA network-object host ABC network-object host BCD group-object blabla access-list nat_outbound extended permit ip object-group TEST any access-list out1 extended permit tcp host ABC host CBA eq ftp access-list out1 extended permit tcp host BCD host DCB eq ssh access-list in1 extended permit tcp host AAA host BBB eq 80 global (outside) 10 interface nat (inside) 10 access-list nat_outbound access-group out1 out interface outside access-group in1 in interface inside Beim Versuch einer http-Verbindung von AAA zu BBB erhalte ich folgenden error: %ASA-7-609001: Built local-host outside:111.111.111.111 %ASA-6-305011: Built dynamic TCP translation from inside:AAA/22412 to outside(nat_outbound):222.222.222.222/1024 %ASA-4-106023: Deny tcp src inside:AAA/22412 dst outside:111.111.111.111/80 by access-group "out1" [0x0, 0x0] Wieso wird hier die access-group out1 agezogen??? P.S. 222.222.222.222 ist die outside IP des interface

Werd´ ich mal testen - danke!

Hallo, wir erlauben einer Servicefirma Ihren Server in unserem Netz über VPN (site-to-site) mit RDP zu administrieren. Bis dato lief auch alles ganz gut. Jetzt hat die Firma plötzlich Probleme die RDP-Verbindung herzustellen. Beim Starten des RDP-Client sehe ich auf unserer Seite mittels wireshark die Pakete auch ankommen, jedoch erhält der Client keine Möglichkeit der Eingabe von User und PW, sondern erhält nach einiger Zeit eine Fehlermedlung aufgrund eines Netzwerkfehlers nicht aufgebaut werden kann. Merkwürdigerweise sehe ich außer den ankommenden Paketen auf dem Terminalserver auch, dass eine Sitzung kurz protokoliiert wird, aber dann wieder abgebaut wird. Dies würde auch auf Clientseite den Connection-Reset erklären, der m.E. für einen aktiven Verbindungsabbau steht. Eine Telnet-Verbindung klappt dagegen einwandfrei. Ich habe das Szenario nachgestellt und habe diese Problematik nicht. Woran könnte es noch liegen? Auf der Remote-Site ist lt. Partner auch alles ok, da sie vom entsprechenden Server nicht nur uns administrieren. Was könnte das Problem sein?

Wenns eine PIX sein soll, dann kommt die 506er in Frage. Hier hast Du zwei physikalische Interface und hast noch zwei virtuelle als VLAN, von denen Du dann eine als DMZ nehmen kannst.

http://www.cisco.com/en/US/customer/products/hw/vpndevc/ps2030/products_tech_note09186a0080094e8a.shtml

Ohne Portfast gibts bei uns massive Probleme bei der Domänanmeldung :mad:

dann stell doch mal das entsprechende syslog ein, dann dürfte es einfacher sein, zu analysieren, warum die acl_out etwas blockt!

Nein, das ist ja das merkwürdige - im logging ist auf keiner Seite was zu sehen. Jenau. Was mir aber aufgefallen ist, im logging des VPN Clients sehe ich die Meldung: Automatic NAT Detection Status: Remote end is not a NAT device This end is not a NAT device Kann es sein, dass der Client dann das Transport Tunneling automatisch auf inactive setzt?