Jump to content

hegl

Abgemeldet
  • Gesamte Inhalte

    704
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von hegl

  1. Verstehe Deine Frage nicht :( Ich natte unser 192-er Netz auf 10.10.10.0 und komme nur mit diesen IP´s beim Partner ins Netz 172.10.x.x Das heißt, bei Paketen aus unserem Netz zu 172.10.x.x wird der Tunnel aufgebaut und unsere internen Adressen auf 10.10.10.0/24 genattet. Beim neuen Tunnel wird analog verfahren: Bei Paketen zu 172.20.x.x soll ein weiterer Tunnel aufgebaut und unsere internen Adressen ebenfalls auf 10.10.10.0/24 genattet werden (weil nur diese im Netz beim Partner rein dürfen).
  2. Ich verzweifele gerade an einer VPN-Verbindung zu einem Kunden. Aktuell existiert bereits ein produktives VPN zu diesem, nun soll/muss aufgrund Netzwerkänderungen beim Kunden parallel ein zweites VPN in Betrieb genommen werden. Der Aufbau sieht von unserer Seite folgendermaßen aus: LAN (192.168.168.0/24) -- NAT (10.10.10.0/24) -- Peer Firma A -- Internet -- Peer 1 Firma B --- Remote LAN (172.10.x.x) So funktioniert´s bisher einwandfrei. Nun soll zu einem anderen Peer mit einem anderen Remote LAN unter Verwendung der gleichen NAT-Range das zweite VPN aufgebaut werden LAN (192.168.168.0/24) -- NAT (10.10.10.0/24) -- Peer Firma A -- Internet -- Peer 2 Firma B --- Remote LAN (172.20.x.x) Leider baut sich aber der Tunnel nicht auf. Ich sehe noch die Meldung "IKE Initiator: New Phase 1, Intf inside, IKE Peer .....", aber dann nichts mehr. Hat jemand eine Idee? Ich habe beide configs verglichen und die sind absolut ok. Kann es sein, dass die ASA hier mit dem NAT zu 2 unterschiedlichen Netzen ein Problem hat?
  3. Kann man standardmäßig im Edge einstellen, dass gemischter Inhalt angezeigt wird, ohne jedesmal den entsprechenden Button zu drücken? Oder erlaubt das die Sicherheitsstruktur dieses Browsers nicht? Ist es vielleicht sogar möglich, dies nur von bestimmten Seiten zuzulassen, die ich als vertrauenswürdig bzw. sicher einstufe?
  4. Jepp, das funktioniert - dankeeeeeeeeeeeeeeeeeee !!!
  5. Das Zertifikat wird als *.pem exportiert und dann in *.cer umgewandelt - das hat ja vor ein paar Wochen funktioniert. Aber ich teste Deinen Vorschlag gerne. Nein, die "Sophos-Generated Certificate Authority" funktioniert ja. Es geht lediglich um das auf der Sophos selbst erzeugte Serverzertifikat mit einem bestimmten FQDN. Die rechtliche Seite ist von entsprechender Stelle geprüft worden.
  6. Jepp. Bekanntes Problem? Sophos SGxxx Das Problem beim HTTPS-Scanning ist hier, dass Blockmeldungen nicht richtig dargestellt werden. Dazu erzeugt man dann auf dem System ein Zertifikat mit dem entsprechenden Namen, exportiert dieses, macht daraus ein .cer kodiertes Zertifikat und importiert das im Browser.
  7. Nein, steht auf "Alle" Bin auch Rookie bei Zertifikaten, aber welchen privaten Schlüssel muss ich denn haben? Ich habe das Zertifikat des Proxy-Servers installiert und das funktioniert auch. Weiter benötige ich noch eins für die korrekte Anzeige von Fehlermeldungen. Dieses habe ich auf dem Proxy mit dem entsprechenden Namen erzeugt und versuche dies nun im IE zu importieren. Und genau dieses macht Probleme. Das Merkwürdige ist aber, dass das in der Testphase vor 2 Monaten wunderbar funktionierte, da haben wir auf 10 Clients in der AD beide Zertifikate problemlos installieren und deinstallieren können. Vielleicht ein MS-Update die Ursache? Ich habe nun auch einmal versucht beide Zertifikate im Firefox zu importieren. Auch hier macht das eine wieder Probleme: Unter Zertifikate\Server scheint er den Import zu machen, sehe aber auch nachher hier das Zertifikat nicht. Versuche ich den Import über Zertifikate\Ihre Zertifikate meckert er den von @g2sm genannten fehlenden privaten Schlüssel an. Nur, welcher ist das??
  8. Genau das habe ich doch manuell nachher gemacht: In der Konsole sichtbar, im IE11 nicht :-(
  9. Für HTTPS-Scanning auf einem Proxy-Server müssen wir 2 Zertifikate (xxx.cer) auf jeden Client (Win7 mit IE11) installieren. Dies wurde durch GPO gelöst. Leider wird im IE im entsprechenden Bereich (Vertrauenswürdige Stammzertifizierungsstellen) nur eins der beiden Zertifikate angezeigt, über die MMC sind beide zu sehen. Selbst wenn ich dann beide noch einmal lösche und anschließend manuell importiere (beides Mal positive Rückmeldung: Importvorgang erfolgreich) sehe ich die Zertifikate zwar über die Konsole, aber nur eins im IE. Dementsprechend gibt´s bei speziellen HTTPS-Requests zerstückelte Websites. Wo kann ich hier ansetzen?
  10. hegl

    LDAP ASA

    Oki, dynamic access policy schaue ich mir mal an
  11. hegl

    LDAP ASA

    Hallo, ich teste gerade die LDPA-Authentifizierung für AnyConnect (ASA 8.2.3). Soweit habe ich das jetzt auch ans Laufen gebracht. User in der AD-Gruppe SSL_VPN_Benutzer können sich per AnyConnect verbinden. ldap attribute-map AnyConnect-LogIn map-name memberOf IETF-Radius-Class map-value memberOf CN=SSL_VPN_Benutzer,OU=Gruppen,OU=Firma,DC=xyz,DC=de sslvpngroup dynamic-access-policy-record DfltAccessPolicy aaa-server LDAP_SRV_GRP protocol ldap aaa-server LDAP_SRV_GRP (inside) host DC01.xyz.de server-port 636 ldap-base-dn DC=xyz,DC=de ldap-scope subtree ldap-naming-attribute sAMAccountName ldap-login-password * ldap-login-dn CN=Admin,CN=Builtin,DC=xyz,DC=de ldap-over-ssl enable server-type microsoft ldap-attribute-map AnyConnect-LogIn aaa local authentication attempts max-fail 3 webvpn enable outside svc image disk0:/anyconnect-win-3.1.06073-k9.pkg 1 svc enable tunnel-group-list enable group-policy NoSSLAccess internal group-policy NoSSLAccess attributes vpn-simultaneous-logins 0 group-policy sslvpngroup internal group-policy sslvpngroup attributes dns-server value DNS-Server1, DNS-Server2 vpn-simultaneous-logins 3 vpn-tunnel-protocol svc split-tunnel-policy tunnelspecified split-tunnel-network-list value split-tunnel default-domain value xyz.de split-dns value xyz.de msie-proxy method no-proxy webvpn svc keep-installer installed svc rekey time 30 svc rekey method ssl svc ask none default svc tunnel-group sslgroup type remote-access tunnel-group sslgroup general-attributes address-pool anyconnect-pool authentication-server-group LDAP_SRV_GRP LOCAL authentication-server-group (inside) LDAP_SRV_GRP LOCAL default-group-policy NoSSLAccess tunnel-group sslgroup webvpn-attributes group-alias sslgroup_users enable Wenn ich nun eine weitere Gruppe der AD, z.B. Fremdfirmenmitarbeiter auch für bestimmte Ressourcen zulassen will, was muss ich dann tun? Wie ist hier die Vorgehensweise, hat jemand einen Link zu einer Beispielkonfiguration? Weiterhin hattte ich gedacht, dass nach obigerKonfiguration auch eine Anmeldung mit einen loaklen User (auf der ASA eingerichtet) funktioniert. Offensichtlich aber nicht, wo ist hier noch was zu konfigurieren?
  12. Als Rückmeldung: Bei einer "Static Policy Nat Rule" kann ich als source keine network-group mit meheren Netzen anziehen - das bietet mir der ASDM auch erst gar nicht an (warum sollte es dann per CLI gehen?). Also habe ich für jedes interne Netz die ACL für das static-command einzeln angelegt: access-list A2B extended permit ip 10.10.10.0 255.255.255.0 172.16.10.0 255.255.255.0 access-list A2B extended permit ip 10.10.11.0 255.255.255.0 172.16.10.0 255.255.255.0 access-list A2B extended permit ip 10.10.12.0 255.255.255.0 172.16.10.0 255.255.255.0 und nicht object-group network Internes-LAN network-object 10.10.10.0 255.255.255.0 network-object 10.10.11.0 255.255.255.0 network-object 10.10.12.0 255.255.255.0 access-list A2B extended permit ip object-group Internes-LAN 172.16.10.0 255.255.255.0 Dann funktioniert auch static (inside,outside) 192.168.10.0 access-list A2B
  13. Ok, habe jetzt die Eskalationsmeldungen deaktiviert. Da es ein externer Partner ist, kann ich auch nicht so ohne weiteres dort die Ressource permanent abfragen.
  14. Ich prüfe einfach, ob der Tunnel aktiv ist oder nicht. Dazu gibt es in PRTG einen enstprechenden Sensor, der die ASA abfragt.
  15. Wir überwachen unsere VPN-Verbindungen zu unseren Remote-Standorten mittels PRTG. Bei einem neuen VPN zu einem Partnern, wo wir Ressourcen nutzen, habe ich die Überwachung analog eingestellt und musste heute Morgen feststellen, dass diese Überwachung nur zu gut funktioniert :cool: Mein Problem ist jetzt aber, dass der Tunnel, nachdem kein traffic mehr produziert wurde, sich abbaut und erst heute Morgen bei Anforderung durch initiierten traffic wieder hoch kam. Ehrlich gesagt hatte ich mir dazu noch nie Gedanken gemacht und würde nun gerne wissen, ob es einen Parameter gibt, wo der Tunnel ohne entsprechenden traffic abgebaut wird oder warum dieser bei unseren Remote-Standorten auch nachts immer up ist.
  16. Jepp, noch keine Lösung in Sicht :confused:
  17. Für ein Site-2-Site VPN hat mir der Partner eine IP-Range (24-er Subnet) genannt, worauf unsere Adressen genattet werden müssen. In einer Testumgebung funktioniert das auch solange, wie ich bei uns auch nur mit einem Class-C-Netz arbeite. Von meiner 10-er Netz muss ich Ressourcen im 172-er erreichen. Der Partner gibt mir als erlaubte IP-Adressen das 192-er vor - soweit funktioniert das auch. access-list A2B extended permit ip 10.10.10.0 255.255.255.0 172.16.10.0 255.255.255.0 access-list VPN-NAT extended permit ip 192.168.10.0 255.255.255.20 172.16.10.0 255.255.255.0 static (inside,outside) 192.168.10.0 access-list A2B ... crypto map mymap match address VPN-NAT ... In der Praxis habe ich aber in unserem LAN mehrere Class-C Netze die ich auf das vom Partner vorgegebene eine Class-C Netz natten muss. Konfiguriere ich dann : object-group network Internes-LAN network-object 10.10.10.0 255.255.255.0 network-object 10.10.11.0 255.255.255.0 network-object 10.10.12.0 255.255.255.0 access-list A2B extended permit ip object-group Internes-LAN 172.16.10.0 255.255.255.0 access-list VPN-NAT extended permit ip 192.168.10.0 255.255.255.20 172.16.10.0 255.255.255.0 static (inside,outside) 192.168.10.0 access-list A2B erhalte ich nach Eingabe des static-command ERROR: access-list used in static has different local addresses Wie komme ich hier raus?
  18. Okay, Frage selbst beantwortet: Ich kann keinem anderen physikalischen Interface eine IP-Adresse aus einem bereits genutzten Netz geben. Aber noch einmal zur eigentlichen Frage: Was passiert, wenn ich die beiden Sites mit unterschiedlicher MTU konfiguriere? Bekomme ich da beim Aufbau bzw. dann nachher bei der Stabilität des Tunnels schon Probleme? Könnte ich dies dann mit einer entsprechenden Wahl der DF-Bit Parmater begegnen?
  19. Na ja, die techn. Begründung ist, dass dies eine Optimierung des Tunnels darstellt und man so möglichen Problemen aus dem Weg geht. Ist aber auch müßig darüber zu diskutieren; wenn dies die Vorgaben des Partners sind, muss ich wohl oder übel in den sauren Apfel beißen und von unserem Standard weggehen. Auf unsere ASA habe ich noch das ein oder andere physikalische interface frei. Kann ich einem dieser interface dann auch einfach eine freie IP-Adresse aus dem outside-LAN geben und den Tunnel darüber realisieren?
  20. Wir haben zur Zeit einige VPN´s zu anderen Locations (Partner, aber auch eigene). Bei einem neuen VPN verlangt der Partner nun eine MTU von max 1380. Bei uns läuft noch alles auf Standard, sprich 1500. Was passiert, wenn ich nun auf dem interface die MTU auf diese 1380 begrenze? Okay, bei den manchen, eigenen Remote-Standorten könnte ich das auch entsprechend anpassen, bei anderen eigenen Standorten habe ich bei der eingesetzten HW nur die Möglichkeit Path MTU Discovery zu aktivieren. Würde dies ausreichen? Problematisch wird es natürlich mit den Partnern, wie die dazu stehen. Auch müssten wir doch wohl alle VPN-Clients anpassen und dort in den MTU Options von Default auf auf Custom umstellen? Wäre also die sinnvollere Lösung, eine separate HW für dieses neue VPN bereitzustellen?
  21. Das ist ein Beispiel - sorry. In der Realität geht es um gloabale IP´s, die wir intern nutzen. Setze also die 10.10.0.0/16 gleich z.B. 150.150.0.0/16 und unsere internen Adressen dann 150.150.150.0/24 An dem Remote-Standort kann ich zudem nichts ändern. Mir geht´s auch hier um das Verständnis, warum das so ist. Zur Zeit müssen die VPN-Clients halt damit leben, dass sie nicht ins Internet kommen, bis ich eine Lösung über das interne LAN (z.B. mit Proxy) installiert habe.
  22. Nein, die ist auf dem Router.
  23. Folgende Situation wie im Anhang dargestellt. Die User greifen vom Remote Standort via Cisco VPN Client auf die Zentrale zu. Dies funktioniert auch solange, bis split-tunneling aktiviert wird. Dies liegt wohl offensichtlich an dem statischen Routing-Eintrag, welcher im Remote-Netzwerk besteht. Hier scheint beim Tunnelaufbau in der Phase 2 - vermutlich beim Erzeugen der SA´s - der Verbindungsaufbau fehlzuschlagen. Was aber genau wird da geprüft, das der Aufbau fehlschlägt? Schicke ich alles in den Tunnel, also ohne split-tunneling, funktioniert es wunderbar; aktiviere ich split-tunneling und konfiguriere nur das Netz 10.10.10.0/24 für den Tunnel, kommt der Tunnel nicht zustande.
  24. Ich habe in der Group Policy für den Remote Access die Simultaneous Logins auf 1 gesetzt (Was ist hier eigentlich Standard bei Inherit?). Wenn ich mich nun mit dem gleichen User anmelde, wirft die neue Verbindung die Erste raus. Ist das normal oder kann ich das unterbinden? Eigentlich sollte der Zweite doch irgendwie eine Meldung erhalten, dass der User bereits in Benutzung ist? ASA Version 8.2(3) auf ASA5520.
×
×
  • Neu erstellen...