mr._oiso
-
Gesamte Inhalte
352 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von mr._oiso
-
-
Hi Chrissie,
poste doch mal folgende Output's !
Ich denke Dein Channel steht noch nicht richtig !
VS0129504802#sh int gig 0/1 sw
Name: Gi0/1
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk (member of bundle Po2)
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Trunking VLANs Enabled: 1,10,20,186,1002-1005
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none
VS0129504802#sh spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 8192
Address 0005.7497.3900
Cost 3
Port 65 (Port-channel2)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0009.7c4a.10c0
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Po2 Root FWD 3 128.65 P2p
Daran können wir sehen ob der Channel überhaupt arbeitet !
Greez from Mr. Oiso
-
hi hegl,
bist Du gezwungen worden das zu konfigurieren oder machst Du das
freiwillig ? :D
Egal: FQDN sollte eigendlich nicht abgefragt werden !
Daher scheint das Problem schon ernster.
Hast Du denn die ganzen Registry Einstellungen für den Client (Windoofs)
gemacht ?
Die sind auf jeden Fall genau (peinlichst genau) zu machen, sonst geht nix.
Ich habe eine Konfiguration im Feld mit L2TPoIPSec welche "Gott sei Dank"
läuft. Unter Version 7.2.2 recht stabil !
Hast Du auf die "crypto map" geachtet ?
Habe sowohl in der dynmap den L2TP ganz am Ende (highest ID) als wie in der gebundenen map am Interface (outside) auch.
Ohne dem, ist es damals auch nicht gegangen.
Die einzelnen Fhler jedoch habe ich nicht mehr auf dem Schirm, welche mir dabei über den Weg gelaufen sind !
Notfalls teste ruhig mal "crypto isakmp identity auto" !
Und mach mal nen "debug crypto ipsec 7"
oder gleich die "debug crypto ipsec 100"
Greez
Mr. Oiso
-
hi diavolo86,
re ! :D
Wie in Teil 1 beschrieben, trifft PAT natürlich nur zu, wenn hier folgendes zuvor passiert ist. Sofern ein "static" inside to outside konfiguriert ist,
werden die externen Adressen "reserviert", ist das nicht der Fall,
so werden die verfügbaren Adressen A.B.C.53-54 und 57-62 der Reihe nach
aufgebraucht, 1:1 Nat, und dann erst geschieht PAT via Interface, also der 50
global (Extern) 1 A.B.C.57-A.B.C.62 netmask 255.255.255.240
global (Extern) 1 A.B.C.53-A.B.C.54 netmask 255.255.255.240
global (Extern) 1 interface
Soweit noch alles o.k.
Jetzt aber meine Frage !
access-list Extern_nat0_outbound extended permit ip any A.B.0.0 255.255.0.0
nat (Extern) 0 access-list Extern_nat0_outbound
Alles, was von extern nach intern soll, dafür gilt mit disen zei Einträgen
plötzlich kein Nat mehr ? Wozu ?
Damit sind diese beiden Nat Entries
static (Extern,Intern) A.B.80.51 A.B.80.41 netmask 255.255.255.255
static (Extern,Intern) A.B.80.52 A.B.80.42 netmask 255.255.255.255
gleich mal "unwirksam" , wobei ich eher glaube, dass du hier mit der externen IP 51 die interne 41 erreichen willst, und dann sollte der command so aussehen
static (Intern,Extern) A.B.80.51 A.B.80.41 netmask 255.255.255.255
Letztendlich zu diesen commands
static (Extern,Extern) A.B.80.50 A.B.80.40 netmask 255.255.255.255
static (Extern,Extern) A.B.C.53 access-list Extern_nat_static
welchen Sinn verfolgst du damit ?
Soweit ich das weiss, macht es nur Sinn, in zum Beispiel so einem Fall:
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml
Aber auch danach sieht es nicht aus !
Und...
static (Extern,Extern) A.B.C.53 access-list Extern_nat_static
sollte sicherlich nen https forwarding von der interface extern IP auf die 80.15 intern werden ! oder ?
von dem hier ganz zu schweigen,
static (Extern,Extern) A.B.80.50 A.B.80.40 netmask 255.255.255.255
sind 80.50 und 80.40 nicht Adressen......ah, 40-42 waren die aus dem vpn pool....:confused: wieso wieder zu 80.50-52 :confused:
Ich glaube eine Netzwerkskizze wäre angebracht.
Und ändere mal A.B.C.53 in reale Zahlen wie 1.2.3.53 und für A.B.80.50
dann 1.2.80.53
Irgendwie komme ich mit der Konfiguration noch nicht ganz klar ! :(
Muss da mal ne Nacht mit schlafen ! :o
Bimo
Greez
Mr. Oiso
-
hi diavolo86,
:suspect:
die Konfiguration ist ja starker Tobak !
Aber eine Frage sei erlaubt, was soll die ASA letzt endlich machen.
Ich gehen mal davon aus, dass diese Konfiguration die ist, welche nicht läuft.
Daher fangen wir am besten klein an !
Diese NAT Rule ist klar, das Netzwerk A.B.0.0/16 am Internen Interface soll
genattet werden !
Also normales PAT via Extern -> sämtliche Adressen aus A.B.0.0/16 werden über die ASA zu A.B.C.50. (Aussnahmen "access-list Intern_nat0_outbound")
bewirkt durch -> nat (Intern) 1 A.B.0.0 255.255.0.0
interface Ethernet0/0
description Extern
nameif Extern
security-level 0
ip address A.B.C.50 255.255.255.240
ospf cost 10
---------------------------------------------------
Alle Adresse, welche durch ACL "access-list Intern_nat0_outbound" erkannt werden, sind davon ausgenommen.
Bedeutet, wenn ein Host aus dem Netzwerk A.B.0.0/16 nach host A.B.80.40-42 möchte, soll kein NAT gemacht werden !
bewirkt durch -> nat (Intern) 0 access-list Intern_nat0_outbound
und
access-list Intern_nat0_outbound extended permit ip A.B.0.0 255.255.0.0 host A.B.80.40
access-list Intern_nat0_outbound extended permit ip A.B.0.0 255.255.0.0 host A.B.80.41
access-list Intern_nat0_outbound extended permit ip A.B.0.0 255.255.0.0 host A.B.80.42
Im Zusammenhang mit :
ip local pool VPN_Intern A.B.80.40-A.B.80.49 mask 255.255.0.0
sieht es so aus, als wenn die ersten drei Mobilen User (dynamic VPN) ins
Interne Netzwerk dürfen (zumindest könnten) und dies restlichen 43-49 (7)
nicht.
Ist das so gewollt ? Interpretiere ich richtig ?
Und Du bist dir bewusst, dass Du für den mobilen User Adressen aus dem Internen Netzwerk verwendest, welche du dort auch frei haben solltest ?
Soviel erst einmal zu Teil 1
Greez
Mr. Oiso
-
hi diavolo86,
hier die Antwort zu letzten Frage: ja !
Was meine ich mit global !
NAT: Local and Global Definitions [iP Addressing Services] - Cisco Systems
Du legitimierst quasi die ASA damit auf Adress-Räume zu reagieren.
Mit dem Befehl "global (outside) 1 interface"
Bezieht sie sich also genau auf dass, was am Interface konfiguriert wurde.
z.B. einen Adress-Raum 100.100.100.1/24
Diesen Eintrag verwendet sie für ihre Nat-Rules.
Ist der Eintrag z.B. nur 100.100.100.1/32 am Interface, dann
wäre "global (outside) 1 interface" das selbe wie global (outside) 1 100.100.100.1
Mit dem Befehl 100.100.100.1-100.100.100.3 beschränkst Du nur den Adr.-Raum für die Adressen die sie dazu verwenden soll.
Bei der ASDM müsste ich also erst nachschauen wo Du das einstellen kannst ! :confused:
Deshalb wage doch mal den Schritt: telnet 200.200.200.1
und zeige uns hier den Output von "show run"
Tip: Nimm bitte sämtliche Passwörter raus, und vergiss dabei DNS-namen nicht, wenn es sich um eine Finale Konfiguration handelt.
Somit können wir auch gelich die ACL's mal einsehen !
Die sind nämlich immer gerne "Big-Problems"
Greez
Mr. Oiso
-
Hi hegl,
die Lösung ist:
access-list ipsecPolen extended permit ip host 10.10.11.222 192.168.20.0 255.255.255.0
no access-list ipsecPolen extended permit ip 192.168.20.0 255.255.255.0 host 10.10.11.222
access-list ipsecPolen extended permit icmp host 10.10.11.222 192.168.20.0 255.255.255.0
no access-list ipsecPolen extended permit icmp 192.168.20.0 255.255.255.0 host 10.10.11.222
Auf der ASA, welchen den IPSec Traffic umleitet/weiterreicht, darf diese Policy nicht so aussehen wie bei mir.
Ich weiss auch nicht welche Pferde mich geritten haben eine solche Policy zu verwenden. (sicherlich irgendwo abgeschrieben) :D
Unter normalen Umständen ist das auch nicht störend !
So laufen zumindest mehrere Tunnel bei mir im Feld.
Gemacht habe ich dieses wahscheinlich irgendwo im Zusammenhang mit einer
Watchguard. Bei der z.B. wird manchmal eine Policy so eingetragen.
A.B.C.D <-> E.F.G.H (bidirectional)
Normal wäre jedoch bei Cisco immer:
permit Prot. local remote
Und das auf beiden Seiten !
Da ich aber hier
permit Prot. local remote
permit Prot. remote local
verwendet habe, haben sich die Pakete des Mobile Client zwischen den ASA's
im Kreis bewegt.
Mit anderen Worten:
Die ASA in der Mitte des Szenarios hat die Pakete nicht mehr an den Client zurück gegeben, sondern an die ASA von der sie das Paket bekommen hat zurück geleitet. :D
Mit noch anderen Worten:
Immer schön dass machen, was im Guide steht, wenn es einen gibt ! ;)
Greez @ all
Nice Weekend
Mr. Oiso
-
hi again,
check out :
global (outside) 1 100.100.100.1-100.100.100.3
Und poste mal den Guide aus dem Du die Sache mit dem Subinterface hast !
Nice evening
Greez
Mr. Oiso
-
hi diavolo86,
genau, ja das meine ich.
Ein Beispiel wie ich es im Feld laufen habe:
interface Ethernet0/0
description External
nameif outside
security-level 0
ip address A.B.C.91 255.255.255.248
global (outside) 1 interface
nat (inside) 0 access-list nonat
nat (inside) 1 172.16.0.0 255.255.0.0
nat (dmz) 0 access-list nonat
nat (dmz) 1 10.0.0.0 255.255.255.0
static (dmz,outside) tcp interface smtp 10.0.0.4 smtp netmask 255.255.255.255
static (dmz,outside) tcp A.B.C.92 www 10.0.0.6 www netmask 255.255.255.255
static (dmz,outside) tcp interface pop3 10.0.0.4 pop3 netmask 255.255.255.255
static (inside,dmz) 10.0.0.102 172.16.1.4 netmask 255.255.255.255
static (inside,dmz) 10.0.0.103 172.16.1.29 netmask 255.255.255.255
Allerdings hast Du mich jetzt wahrscheinlich auf dem falschen Fuss erwischt :D
Ich fahre hier eine ASA5510 mit Version 7.2.2 und ohne Vlan Lizenz.
Jedoch bin ich der Meinung, das die Vlan's hier keine Rolle spielen, da sie
letztlich auch nameif outside konfiguriert sind.
Natürlich solltest Du darauf achten, dass Du die allg. NAT Rule im Griff hast und eine "outside_access_in in interface outside" hast, welche den syn https durchlässt.
Ohne den HTTPS von aussen frei zu machen, kann die static PAT (NAT) rule nicht funktionieren.
Ich werde es auf jeden Fall zum Wochenende mal selber im Release 8.0.3 testen, da ich dort auch nen https Citrix WebAccess benötige.
Ansonsten ist aus diesem Dokument viel rauszuholen !
Greez
Mr. Oiso
-
Hi@all,
hi hegl
Tja, Fehlermeldung Fehlanzeige.
Mit dem "same-security-traffic" ist zumindest einmal schon das IPSec Relay,
aktiv. IPSec Traffic am Umlenkpunkt rein und raus.
#pkts encaps: 40, #pkts encrypt: 40, #pkts digest: 40
#pkts decaps: 45, #pkts decrypt: 45, #pkts verify: 45
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 40, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing
reassembly:0
#send errors: 0, #recv errors: 0
Das tut's schon mal !
Das Dumme ist jedoch, dass man den Traffic schlecht capture'n oder filtern kann, da er eben encrypted sein sollte.
Am Endpunkt, also der zweiten ASA kann man ihn dann capture'n am inside interface. Danach jedoch passiert schon folgendes in der SA.
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 19, #pkts decrypt: 19, #pkts verify: 19
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing
reassembly: 0
#send errors: 0, #recv errors: 0
Die ASA entschlüsselt noch den request (z.B. ICMP), den man dan capture'n kann, man sieht auch noch den reply wieder reinkommen am inside, aber dann
wird nicht verschlüsselt.
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 :confused:
Vor allem :confused: , weil neben diesem Tunnel ein normaler L2L liegt, welcher einwandfrei läuft.
Jetzt hab ich schon 37 mal die Nat Rule geprüft und ACL's rein und raus genommen ............... :(
Bleibt jetzt nur noch die Frage nach den Releases und ihren Bug's.
Oder z.B. auch die Frage:
Im Guide gelten für alle Tunnel die gleichen encryption parameter z.B. 3des/sha sowohl für die dynamischen Clients als wie auch für den static.
Ich jedoch nutze Release 8.0.3 und 7.1.2
Ausserdem eine ASA mit 3des und die andere mit des Lizenz.
Ergo muss der IPSec einmal von 3des auf des zurück und umgekehrt.
Ob das Probleme bereitet.
Mal sehen was Cisco sagt.
Ich mach mal nen Test mit einem dynamischen User und einer des Verschlüsselung - Eben "Guided"
Update folgt.
Nice evening
Greez
Mr. Oiso
-
Hi @ all
so weit so gut.
Den netten Link aus dem letzten Post hab ich wohl selbst nicht richtig gelesen,
"same-security-traffic permit intra-interface"
war der erste Schlüssel zum "fast" Erfolg.
Leider läuft es immer noch nicht.
Jedoch lässt sich nun auf der entfernten ASA im cature sehen, dass z.B.
ein ICMP reply vom Mobile-User der ersten ASA reinkommt und auch
der reply ist von der dst-ip die ASA in Richtung inbound trusted wieder
betritt.
34: 02:03:48.290298 802.1Q vlan#1 P0 10.10.11.222 > 192.168.20.3: icmp: echo request
35: 02:03:48.290451 802.1Q vlan#1 P0 192.168.20.3 > 10.10.11.222: icmp: echo reply
Danach jedoch ist Schluss ! :confused:
capture, debug, study ................... :cry:
Greez
Mr. Oiso
-
hi @ all,
für alle, denen mein Roman :D nicht ganz eindeutig ist.
Hier soll es hingehen !
Greez
Mr. Oiso
-
Hi diavolo86,
ein "forwarding" static sollte hier reichen.
static (inside,outside) tcp 100.100.100.3 https 200.200.200.10 https netmask 255.255.255.255
Greez
Mr. Oiso
-
Hi hegl,
nice tip to use object groups ! :D
Wie ich sagte ein Alias für Services und Address-Spaces etc. !
:cool: Feature !
Ist das neu in Version 8 ?
thx
Greez
-
Hi Wordo, hi hegl,
@Wordo: sowas würde ich nie machen ! ;)
@hegl: Gute Frage, da schau ich doch gleich mal nach was Du mit "network-objects" meinst. Zu meiner Schande habe ich mir dazu noch keine Gedanken gemacht.
Sicherlich ist das nichts anderes als ein Alias für die Destination-Netzwerke welche ich erreichen will, oder liege ich da falsch.
Generell, meine ich mit 10.10.11.0/24 - 192.168.20.0/24, einmal den dynamischen Pool der mobilen VPN Clients welcher 10.10.11.0/24 ist und
ein destination network hinter einem static Tunnel !
Die mobilen User haben einen normalen VPN-Connect welcher funktioniert zum local/trusted network welches 192.168.1.0/24 ist.
Wenn ich hier eine policy definiere mit:
split-tunnel-policy tunnelall (default)
split-tunnel-policy value "list"
und die "list" (standard) permit 192.168.1.0 255.255.255.0
funktioniert soweit alles ganz gut.
Nur bis dahin alles "Easy"
Jetzt besitzt die ASA aber noch einen static Tunnel
192.168.1.0/24 - 192.168.20.0/24
Dieser ist ebenfalls funktionstüchtig und läuft.
Jetzt habe ich die Routing-Policy IPSEC (SA) um die Einträge
permit 192.168.20.0 255.255.255.0 10.10.11.0/24
erweitert.
Das sorgt dafür, dass ich zwischen den static peer's nun eine policy habe,
welches den mobile Usern ermöglichen sollte über ihre VPN Verbindung auch
das Netzwerk 192.168.20.0/24 zu erreichen.
sh crypto ipsec sa - auf den static peer's zeigt mir auch eindeutig den Tunnel.
Nur sehe ich keine encrypt/decrypt packets, solange das "slpit-tunneling" der
mobilen User nicht richtig arbeitet.
Habe also die "list" (standard) permit 192.168.1.0 255.255.255.0 um
permit 192.168.20.0 255.255.255.0 erweitert und bekomme die beim VPN-Client unter "Status/Statistics/Route Details" auch angezeigt.
ACL's habe ich bereits alle geprüft und zwischenzeitlich auch auf "ip any any" inkl. "icmp any any" gehabt. Ohne Ergebnis !
Irgenwas stimmt mit dem Routing oder dem Split-Tunneling nicht !
Aber was ?
-
Hi @ all,
da habe ich doch glatt auch einmal ein Problem.
Wahrscheinlich bin ich aber auch nur blind !
Ich versuche schon seit Freitag Split-Tunneling auf einer ASA einzurichten,
aber irgendwie will es nicht funktionieren.
Anbei meine Konfiguration (Ausschnitte)
Die Client's aus 10.10.11.0/24 sollen durch den Tunnel nach 192.168.20.0/24
Was hält sie auf ?
Danke für jedes wachsame Auge !
Greez
Mr. Oiso
-
Mahlzeit Leute,
kleiner Tip, "copy flash:vlan.dat tftp" und auf den neuen Switch
wieder hochladen, reload und fertig ! :D
So hat man auch gleich ne Sicherung, falls einem das Pech mit einer
neuen und zu hohen Config Revision Number ereilen sollte. ;)
Greez
Mr. Oiso
-
hi jon,
um die ein oder andere dialer map/pool oder profile Konfiguration wirst Du hier wohl nicht herum kommen. Und solange du die 30 Kanäle nicht aufbrauchst, kannst du die Verbindungen ja auch an Sub-Interfaces binden
P.S.: Example TechNotes bei cisco gibt es sogar ohne CCO Login !
check this out:
ISDN, CAS Configuration Examples and TechNotes - Cisco Systems
Greez
Mr. Oiso
-
Hi maegl, hi hegl,
@hegl, sorry für die ...... (Du weisst schon), ich nehme es halt gern genau ! ;)
Aber nur so erklärt sich oft vieles von alleine !
Im Debug Output gab es bis auf:
Feb 15 09:38:28 [iKEv1 DEBUG]: Group = x.x.x.x, IP = x.x.x.x, IPSec SA Proposal # 1, Transform # 1 acceptable Matches global IPSec SA entry # 10
keine Fehler, nur in diesem Eintrag ist genau zu sehen, dass die Phase 2 auf die falsche IKE Policy aufsetzt. "Matches global IPSec SA entry # 10"
Eigendlich hätte hier die # 20 stehen müssen, damit der Tunnel nach Vorgabe in beiden
Richtungen hätte funktionieren können.
Auch die Entnahme der "set reverse-route" kann die Aktion begünstigt haben, welche mir gestern Abend dann im Bett auch sinnlos erschien, weil die Policy doch anhand einer
L2L hätte direkt matchen dürfen.
Habe da anfänglich leicht dran vorbei geschaut, obwohl Du eine pppoe mit dynamic IP am outside laufen hast.
Ich dachte mir aber schon, dass Du sicherlich eine endlose "lease" bekommst, und daher war ansonsten auch alles richtig.
Eine weitere mögliche Lösung wäre gewesen:
Verwende solange es die Resourcen der Hardware zulassen unterschiedliche IKE Proposal's, um solche Fehler zu umgehen (oder bename sie einfach anders).
Richtig lustig wird es erst noch wenn man nun auch noch L2TPoverIPSec oder gar SSLVPN
Policies mit einarbeitet !
Schön, dass ich helfen konnte !
Und sollten noch Fragen offen sein, nur zu !
Nice evening !
Greez
Mr. Oiso
-
Hi maegl,
jo, jo, ich habe mir etwas viel Zeit gelassen, sorry.
Aber ich denke mal ich kenne die Lösung.
Pack doch mal bitte Deine
crypto map VPNBO 10 ipsec-isakmp dynamic rtpdynmap
an das Ende der map VPNBO
Ich bin mir nicht sicher, ob der "reverse-route" für den
Tunnel zu stande kommt, daher würde ich nach Cisco Beispiel
vorgehen ! Demnach die dynmap immer ans absolute Ende der map,
welche am Outside hängt.
Die Reihenfolge der Crypto map würde ich immer nach der Genauigkeit des
Machting's aufbauen.
Je mehr Parameter für die Policy matchen, desto niedriger die ID
crypto ipsec transform-set vpnboeching esp-3des esp-md5-hmac
crypto dynamic-map rtpdynmap 10 set transform-set vpnboeching
crypto map VPNBO 20 match address VPNRG
crypto map VPNBO 20 set peer X.X.X.X
crypto map VPNBO 20 set transform-set vpnboeching
crypto map VPNBO 20 set reverse-route
crypto map VPNBO 30 match address VPNBA
crypto map VPNBO 30 set peer Y.Y.Y.Y
crypto map VPNBO 30 set transform-set vpnboeching
crypto map VPNBO 40 ipsec-isakmp dynamic rtpdynmap
crypto map VPNBO interface outside
crypto isakmp enable outside
crypto isakmp policy 20
Hier das Beispiel von Cisco
!--- Configuration of IPsec Phase 2
crypto ipsec transform-set myset esp-3des esp-sha-hmac
!--- IPsec configuration for the dynamic LAN-to-LAN tunnel
crypto dynamic-map ezvpn 30 set transform-set myset
!--- IPsec configuration for the static LAN-to-LAN tunnel
crypto map outside_map 20 match address outside_cryptomap_20
crypto map outside_map 20 set peer 172.16.1.1
crypto map outside_map 20 set transform-set myset
!--- IPsec configuration that binds dynamic map to crypto map
crypto map outside_map 65535 ipsec-isakmp dynamic ezvpn
!--- Crypto map applied to the outside interface of the ASA
crypto map outside_map interface outside
isakmp enable outside
Sorry, aber meinst Du doppelt gemoppelt hält besser?Erstens hat er die ACL schon und
zweitens, wenn er in der ACL ip freigibt, muss er nicht auch noch icmp freigeben, da ja bekanntlich icmp in ip drin ist !!!
Erstens: Doppelt wäre gewesen,....
access-list VPN extended permit ip 192.168.2.0 255.255.255.0 192.168.10.0 255.255.255.0
access-list VPN extended permit ip 192.168.2.0 255.255.255.0 192.168.10.0 255.255.255.0
und überhaupt,
ICMP war noch nie "in IP drin" .............. !!! (wie sich das schon anhört) :suspect:
Refer to:
RFC 1122 Requirements for Internet Hosts -- Communication Layers
Zitat RFC1122
ICMP is a control protocol that is considered to be an
integral part of IP, although it is architecturally
layered upon IP, i.e., it uses IP to carry its data end-
to-end just as a transport protocol like TCP or UDP does.
ICMP provides error reporting, congestion reporting, and
first-hop gateway redirection.
IGMP is an Internet layer protocol used for establishing
dynamic host groups for IP multicasting.
The Internet layer protocols IP, ICMP, and IGMP are
discussed in Chapter 3.
ICMP also arbeitet nach wie vor auf der selben OSI Schicht wie IP, und zwar in der
Vermittlungsschicht (Layer3). Und "in IP drin" kann es daher per Definition nicht sein.
Refer to: Open Systems Interconnection Reference Model
Wenn wir nun also ein Vermittlungschicht Protokoll wie IP in eine IPSec Policy aufnehmen,
um die Grundlage der Vermittlungsart innerhalb des IPSec Tunnel festzulegen, so sei es unter Umständen auch Ratsam, ICMP mit hinzuzunehmen, damit "Deiner Meinung nach" ICMP auch innerhalb des IPSec Tunnel, weiterhin "in IP drin" sein darf ! :D
Greez
Mr. Oiso
-
Hi maegl,
hast Du nach dem Aufbau des Tunnels nur nen Ping geschickt, um den Tunnel zu testen ?
Erweitere mal die IPSec Policy um ICMP
access-list VPN extended permit ip 192.168.2.0 255.255.255.0 192.168.10.0 255.255.255.0
+
access-list VPN extended permit icmp 192.168.2.0 255.255.255.0 192.168.10.0/24
Auf beiden Seiten !
Poste mal nen: debug crypto isakmp & debug crypto ipsec (vom Tunnelaufbau bis über Phase 2 hinweg)
und nen show crypto ipsec sa !
Greez
Mr. Oiso
-
Hi jholzer
Das ist ein ****er Fehler, und ist mir bekannt.
Die Lösung jedoch scheint nicht so Einfach.
In zwei Situationen hatte ich den Felher auch schon einmal.
Einmal mit einem HA active/standby Watchguard Firewall System.
Diese fragen sich gegenseitig via ARP-Request ab.
Hier wechselten die Boxen ständig den active/standby, weil der Cisco Catalyst
nur einen Incomplete ARP entry zurückgegeben hat.
Lösung war: Fix Speed/Duplex 100/full z.B.
In einer anderen Situation war es ein medizintechnisches Gerät, spez. Anfertigung.
Ähnlich wie Deine Elektronik.
Hier jedoch hat das Fixen der Prot's nix gebracht.
Leider liess sich auf der elektronischen Seite die Link Layer nicht beeinflussen,
daher musste ich einen Switch/Release- Wechsel vornehmen um das Problem
zu beheben.
Als erstes würde ich einmal die Verkabelung checken und die Port's fixen.
Also Autonegotiation abschalten.
Dann wäre es Interessant, ob du den Cat3550 als Router oder als reinen Switch
betreibst. Abschalten von IP CEF könnte helfen.
In jedem Fall auch mal ein "debug arp"
Auch helfen könnte der wechsel von Pagp zu LACP, oder gänzlich abschalten.
Auf den folgenden Seiten findest Du .... "leider" eine Menge von möglichen
Ursachen, aber auch möglichen Lösungen.
http://www.cisco.com/en/US/partner/tech/tk827/tk831/technologies_tech_note09186a0080094303.shtml
Da Deine Elektronik wahrscheinlich sehr individuell ist, wird auch die Lösung sehr
individuell sein. Bedenke aber immer den Nutzen gegenüber dem Aufwand.
Greez from
Mr. Oiso
-
Hallo,
ich habe ein recht seltsames Problem:
Ich habe einen SBS2003 mit 10 Cals. Darauf gibt es 8 Exchange-Postfächer und eine Hand voll Freigaben.
Nun kommt es in unregelmaessigen Abständen dazu das jemand nicht mehr via Outlook auf sein Exchange-Postfach zugreifen kann. OWA oder der Zugriff auf freigegebene Ordner funktioniert weiterhin nur eben der Zugriff auf das Postfach via Outlook nicht. (Outlook 2003 SP3!).
Wenn man den Server neu startet so funktioniert der Zugriff wieder eine Zeit lang.
In den Eventlogs gibt es leider keine Hinweise oder Fehler - auch auf dem Client gibt es keinen Hinweis im Eventlog dazu.
Es muss ja irgendein dynamischer Vorgang sein, der durch einen Serverneustart zurück gesetzt wird weil es danach wieder funktioniert.
Kann mir jemand sagen oder vermuten welcher Mechanismus dies sein kann?
Gruß
-
hi erazer2005
hier die wars***einlich schwierigere Version !
Hybrid Mode Cat6509 running CatOS 8.3(3)
set trunk 4/1 desirable dot1q 1-4094
set trunk 4/2 desirable dot1q 1-4094
set trunk 4/3 nonegotiate dot1q 1-4094
set trunk 4/5 desirable dot1q 1-4094
set trunk 4/6 desirable dot1q 1-4094
set trunk 4/7 desirable dot1q 1-4094
set trunk 4/8 desirable dot1q 1-4094
set trunk 4/9 desirable dot1q 1-8,10-12,15-4094
set trunk 4/10 desirable dot1q 1-4094
set trunk 4/11 desirable dot1q 1-4094
set trunk 4/12 desirable dot1q 1-4094
set trunk 4/13 nonegotiate dot1q 1-4094
set trunk 4/14 nonegotiate dot1q 1-4094
set trunk 4/15 nonegotiate dot1q 1-4094
set trunk 4/16 nonegotiate dot1q 1-4094
set spantree portfast 4/1-3,4/5-16 disable
set spantree portfast 4/4 enable
set spantree guard none 4/1-16
set port channel 4/1-4,4/7-8,4/13-16 mode off
set port channel 4/5-6,4/9-12 mode desirable silent
!
#module 5 : 2-port 1000BaseX Supervisor
set port name 5/1 VS33650901DSW1 (112)
set port name 5/2 VS33650901DSW1 (112)
set udld disable 5/1-2
set spantree portfast 5/1-2 disable
set spantree guard none 5/1-2
set port channel 5/1-2 mode desirable silent
Nice Weekend
Greez
Mr. Oiso
-
Hallo,
ich habe ein kleines Problem mit einer Anwendung unter Windows 2000 Server.
Diese Anwendung benötigt eine INI-Datei mit bestimmten Werten die normal auch vorhanden ist.
Nun kommt irgendwann manchmal einmal am Tag, manchmal auch erst nach 3 Tagen es vor das der Inhalt der INI-Datei zwar noch da ist, aber alle Werte in ihr (nur Zahlen) plötzlich auf 0 stehen.
Die Applikation selbst scheint es nicht zu sein die dies verursacht. Da bei der Installation d.h. vor der Konfiguration der Applikation diese INI-Datei auch mit diesen 0-Werten existiert scheint es mir so als ob irgendjemand den Ursprünglichen Zustand der Datei wieder herstellt.
Ich sehe dann zwar das die Werte 0 sind, aber der Zeitstempel der Erstellung dieser Datei ist noch immer der des Installationszeitpunktes der Applikation.
Gibt es eine Möglichkeit, Schreibzugriffe auf diese INI-Datei so zu protokolieren das ich herausfinden kann, wer, welcher Prozess, welches Windows-Konto wann diese Datei verändert hat? Es muss doch irgendein Tool geben was dies leistet oder?
Gruß
Problem inbound Verkehr
in Cisco Forum — Allgemein
Geschrieben
Hi Pete,
also, ...........
Einmal funktioniert es mit Deiner ACL*1, weil Du Dich noch nicht
entschieden hast, ob Du das Packet von 192.168.2.10 nun
routen oder natten willst.
Im Grunde kann die ASA das Packet routen, aber das tut sie eben nur,
wenn Du es in die NAT (Ausnahme) : nat (dmz) 0 access-list CRYPTOACL
über die ACL CRYPTOACL mit aufnimmst !
Deshalb funktioniert es so wie geschildert.
Die Frage 2 und 3 lässt sich schnell erklären.
Am Ende einer jeden ACL steht, auch wenn die ASA es nicht anzeigt:
"access-list DMZ extended deny ip any any"
Daher kann bei ausschließlich diesem Eintrag:
host 192.168.2.10 host 192.168.1.25 anschließend auch nur noch
2.10 mit 1.25 reden !
Na und "permit ip any any" (recht hast Du) Sicher ist das sicherlich nicht !
Mein Vorschlag im nächsten Post
Greez Mr. Oiso
–
Hi Pete,
da ich nicht weiss, was der Server 192.168.2.10 in der DMZ macht.
hier ein allg. Vorschlag:
no access-list CRYPTOACL extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
static (intern,dmz) 192.168.2.x 192.168.1.x netmask 255.255.255.255
Lass die beiden Server über einen statischen NAT Eintrag miteinander kommunizieren. Damit umgehst Du die NAT 0 (Ausnahme).
Für x wähle jeweils eine frei Adresse aus dem internen und dem dmz Netz.
Wenn Du z.B. einen SMTP Proxy hier in der DMZ betreibst ginge auch:
static (intern,dmz) tcp 192.168.2.x smtp 192.168.1.x smtp netmask 255.255.255.255
Statt dem hier:
access-list DMZ extended permit ip host 192.168.2.10 host 192.168.1.25
access-list DMZ extended permit ip any any
Solltest Du die ACL schon genauer definieren:
z.B.:
access-list DMZ extended tcp host 192.168.2.10 any eq smtp
access-list DMZ extended tcp host 192.168.2.10 any eq www
access-list DMZ extended udp host 192.168.2.10 any eq domain
access-list DMZ extended udp host 192.168.2.10 any eq ntp
access-list DMZ extended tcp host 192.168.2.? (andere Server)
access-list DMZ extended udp host 192.168.2.? (andere Server)
oder wenn z.B. 192.168.2.10 ein Terminal Server inkl. Webzugriff für die Remote Side ist
access-list DMZ extended tcp host 192.168.2.10 eq 3389 192.168.110.0 255.0.0.0
access-list DMZ extended tcp host 192.168.2.10 eq www 192.168.110.0 255.0.0.0
access-list DMZ extended icmp host 192.168.2.10 host 192.168.1.25
ICMP in jedem fall erst einmal um zu sehen ob es funktioniert
Nice Weekend
Greez from Mr. Oiso
–
Hi again,
Tips:
Du kannst den static auch weglassen und nur die ACL DMZ einrichten,
musst dann aber
access-list CRYPTOACL extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
stehen lassen.
Der Übersicht wegen mache ich es auf jeden Fall so, damit ich mir nicht bei einer Config ähnliche Gedanken mache.
Und, ich würde die nat 0 an DMZ und intern über getrennte ACL's definieren !
Ciao
Mr. Oiso