MYOEY 10 Geschrieben 15. Juni 2010 Melden Teilen Geschrieben 15. Juni 2010 Hallo, hinter einer remote ASA5505 sind 4 PC's, die alles(IP,DNS,AD,...) per DHCP bekommen sollten. Die ASA5505 ist in einer Niederlassung und der DHCP Server ist in der HQ(ASA5520), zwischen den beiden ASA's wird eine IPSec L2L Tunnel aufgebaut. Der DHCP Server ist quasi auf der andere Seite (outside Seite von der ASA5505). wie kann ich die ASA5505 dazu bringen, die DHCP Requests an den DHCP Server auf der anderer Seite weiterzuleiten und die PC's alles bekommen, was sie brauchen. Gibt’s so was wie „ip-helper address” für die ASA oder sin des andere command? welche commands sollten konfiguriert werden? Besten Dank schon mal im Voraus! Grüße Zitieren Link zu diesem Kommentar
Wordo 11 Geschrieben 15. Juni 2010 Melden Teilen Geschrieben 15. Juni 2010 dhcprelay? Zitieren Link zu diesem Kommentar
Otaku19 33 Geschrieben 15. Juni 2010 Melden Teilen Geschrieben 15. Juni 2010 PIX/ASA 7.x as a DHCP Relay Configuration Example - Cisco Systems Zitieren Link zu diesem Kommentar
hegl 10 Geschrieben 16. Juni 2010 Melden Teilen Geschrieben 16. Juni 2010 Wichtig ist bei DHCP-Relay via VPN, dass die outside-IP der Remote-ASA mit in die crypto-map und die ACL aufgenommen wird. Zitieren Link zu diesem Kommentar
MYOEY 10 Geschrieben 16. Juni 2010 Autor Melden Teilen Geschrieben 16. Juni 2010 Besten Dank für euer Antworten! ich werde es mal testen. Grüße Zitieren Link zu diesem Kommentar
MYOEY 10 Geschrieben 6. August 2010 Autor Melden Teilen Geschrieben 6. August 2010 Ich hab es probiert aber leider ohne Erfolg. die Clients in der Niederlassung bekamen keine IP's!!! debug ist eingeschaltet. Auf der ASA in der Niederlassung sehe ich folgendes: dhcpd_forward_request: request from 001e.3310.3062 forwarded to 10.20.1.1. Also, die Clients schicken dhcp-Request aber kein Reply bzw. wird es nicht an den dhcp-Server weitergeleitet oder so!!! @hegl: was meinst du genauer? was sollte noch konfigurieret werden? bitte commands! vielleicht liegt es noch daran! Danke, Zitieren Link zu diesem Kommentar
sessi 10 Geschrieben 6. August 2010 Melden Teilen Geschrieben 6. August 2010 Hi MYOEY Kommen die discovers an der Gegenseite an? LOG? Gruss Sessi Zitieren Link zu diesem Kommentar
MYOEY 10 Geschrieben 9. August 2010 Autor Melden Teilen Geschrieben 9. August 2010 Nein, die DHCP Requests, die ich auf der ASA in der Niederlassung sehe, kommen nicht an der Gegenseite an!!! Woran könnte es liegen? Danke & Grüße Zitieren Link zu diesem Kommentar
MYOEY 10 Geschrieben 9. August 2010 Autor Melden Teilen Geschrieben 9. August 2010 Log auf der ASA (Niederlassung) sagt: ASA5505# DHCPRA: relay binding found for client 001e.3310.3062. DHCPD: setting giaddr to 192.168.4.1. dhcpd_forward_request: request from 001e.3310.3062 forwarded to 10.20.1.1. "192.168.4.1" ist die IP Adresse des ASA-Interfaces Also, es sieht es aus, als es doch weitergeleitet worden ist aber es kommt an der Gegenstelle nicht an!!! Hier ist die Config der keinen ASA: dhcprelay server 10.20.1.1 outside dhcprelay enable inside dhcprelay setroute inside dhcprelay timeout 90 Zitieren Link zu diesem Kommentar
sessi 10 Geschrieben 9. August 2010 Melden Teilen Geschrieben 9. August 2010 Hi MYOEY Lässt die ASA beim DHCP denn die Discovers inbound durch? Check deine acl`s. Gruss Sessi Zitieren Link zu diesem Kommentar
MYOEY 10 Geschrieben 10. August 2010 Autor Melden Teilen Geschrieben 10. August 2010 (bearbeitet) Ich denke schon! hier sind alle ACL's access-list inside_access_in extended permit ip 192.168.4.0 255.255.255.0 any access-list inside_access_in extended permit icmp 192.168.4.0 255.255.255.0 any access-list outside_access_in extended permit ip 10.20.1.0 255.255.255.0 192.168.4.0 255.255.255.0 access-list outside_access_in extended permit icmp any any access-list noNAT extended permit ip 192.168.4.0 255.255.255.0 10.20.1.0 255.255.255.0 access-list IPSec_ACL extended permit ip 192.168.4.0 255.255.255.0 10.20.1.0 255.255.255.0 Fehlt noch was vielleicht? bearbeitet 10. August 2010 von MYOEY Zitieren Link zu diesem Kommentar
MYOEY 10 Geschrieben 10. August 2010 Autor Melden Teilen Geschrieben 10. August 2010 Ich hab's nun soweit hingekriegt, dass die dhcp requests drüben ankommen :-) Die DHCP Requests kommen nun an der Gegenstelle (ASA5520) an aber sie werden gedropt, hier ist die Zeile aus Log: Aug 10 10:38:16 X.X.X.X %ASA-3-713061: Group = Remote-Office, IP = X.X.X.X, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 0.0.0.0/0.0.0.0/0/0 local proxy 10.20.1.1/255.255.255.255/0/0 on interface outside die ACL auf der Centrale Office sieht wie folgt: access-list noNAT extended permit ip 10.20.1.0 255.255.255.0 192.168.4.0 255.255.255.0 access-list IPSec_ACL extended permit ip 10.20.1.0 255.255.255.0 192.168.4.0 255.255.255.0 wie kann ich nun die ASA in der Zentrale dazu bringen, diesen Request suaber an den DHCP Server (IP:10.20.1.1) weiterzuleiten? welche command fehlen noch? Thanks im voraus! Zitieren Link zu diesem Kommentar
MYOEY 10 Geschrieben 12. August 2010 Autor Melden Teilen Geschrieben 12. August 2010 Na leute, keine Idee/Tipp ... die Clients hinter der ASA5505 kriegen weiterhin keine IP's vom DHCP server! Muß was spezielles an der ASA5520 in der Zentrale konfiguriert werden? Gruß Zitieren Link zu diesem Kommentar
hegl 10 Geschrieben 17. August 2010 Melden Teilen Geschrieben 17. August 2010 @hegl:was meinst du genauer? was sollte noch konfigurieret werden? bitte commands! vielleicht liegt es noch daran! Für die Remote-ASA: access-list outside_cryptomap_10 permit ip host Remote-ASA-outside-IP host DNS-Server access-list outside_cryptomap_10 permit ip <Remote-LAN> <LAN-RZ> access-list 100 permit ip host Remote-ASA-outside-IP host DNS-Server access-list 100 permit ip < Remote-LAN> <LAN-RZ> Analog musst Du natürlich dies auch auf der zentralen ASA konfigurieren. Wenn das laufen sollte, kannst du die ACL´s natürlich auf die nötigsten Ports beschränken. Zitieren Link zu diesem Kommentar
Otaku19 33 Geschrieben 17. August 2010 Melden Teilen Geschrieben 17. August 2010 wenn man sich mit ACLS gerne verhaspelt dann bitte immer captures aufsetzen (bei tunneln halt leider nicht auf beiden Interfaces möglich) und den packet-tracer Befehl nutzen. Dann muss hier auch niemand raten was du so alles in den ACLs stehen hast Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.