20
Cisco 866VAE-K9 ACL-Konfiguration
Hallo!
Uns wurde gestern ein Cisco-Router eingerichtet. Der Techniker hatte aber anscheinend doch nicht sooo die Ahnung von der Kiste, weswegen ich seine Konfiguration gerne mit Euch diskuterien und korrigieren würde.
Erklärung:
Am GE1 hängt das DSL-Modem, am GE0 hängt der Switch vom Netzwerk und am FE3 hängt ein WLan-Access-Point (für Gäste, kein Zugriff aufs Netzwerk an GE0)
1.) denke ich, daß die ACLs 2, 3 und 4 unnütz sind - bin ich da richtig?
2.) habe ich die ACLs 111 eingefügt, um Dienste eines Servers von außen zu erreichen und den Rest zu schließen - ist das so korrekt?
3.) passen die NAT's oder muß das eigentlich anders?
4.) findet jemand weitere Fehler?
Ich würde mich freuen, wenn mir jemand hierbei helfen könnte!
Grüße
Johannes
Uns wurde gestern ein Cisco-Router eingerichtet. Der Techniker hatte aber anscheinend doch nicht sooo die Ahnung von der Kiste, weswegen ich seine Konfiguration gerne mit Euch diskuterien und korrigieren würde.
Erklärung:
Am GE1 hängt das DSL-Modem, am GE0 hängt der Switch vom Netzwerk und am FE3 hängt ein WLan-Access-Point (für Gäste, kein Zugriff aufs Netzwerk an GE0)
1.) denke ich, daß die ACLs 2, 3 und 4 unnütz sind - bin ich da richtig?
2.) habe ich die ACLs 111 eingefügt, um Dienste eines Servers von außen zu erreichen und den Rest zu schließen - ist das so korrekt?
3.) passen die NAT's oder muß das eigentlich anders?
4.) findet jemand weitere Fehler?
Building configuration...
Current configuration : 6426 bytes
!
! Last configuration change at 20:05:15 UTC Thu Jan 23 2014 by root
version 15.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
!
no logging buffered
enable secret 5 XXXXXXXXXXXXXXXXXXXXX
enable password XXXXXXXXXXXX
!
no aaa new-model
no process cpu extended history
no process cpu autoprofile hog
wan mode ethernet
!
!
!
ip dhcp excluded-address 192.168.92.1 192.168.92.129
ip dhcp excluded-address 192.168.92.200 192.168.92.254
ip dhcp excluded-address 192.168.82.1 192.168.82.129
ip dhcp excluded-address 192.168.82.200 192.168.82.254
!
ip dhcp pool standard
import all
network 192.168.92.0 255.255.255.0
dns-server 192.168.92.1 8.8.8.8
default-router 192.168.92.1
!
ip dhcp pool gastwlan
network 192.168.82.0 255.255.255.0
dns-server 192.168.82.1 8.8.8.8
default-router 192.168.82.1
!
!
ip inspect name myfw tcp
ip inspect name myfw udp
!
ip cef
no ipv6 cef
!
!
vpdn enable
!
vpdn-group 1
!
!
!
crypto pki trustpoint TP-self-signed-1437846337
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-1437846337
revocation-check none
rsakeypair TP-self-signed-1437846337
!
!
crypto pki certificate chain TP-self-signed-1437846337
certificate self-signed 01
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
quit
!
!
username XXXXXXXXXXXXXXXXXX privilege 15 secret 4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx
!
!
controller VDSL 0
shutdown
!
!
!
!
!
!
!
!
!
!
!
!
!
interface ATM0
no ip address
shutdown
no atm ilmi-keepalive
!
interface Ethernet0
no ip address
shutdown
no cdp enable
!
interface FastEthernet0
no ip address
shutdown
no cdp enable
!
interface FastEthernet1
no ip address
shutdown
no cdp enable
!
interface FastEthernet2
no ip address
shutdown
no cdp enable
!
interface FastEthernet3
switchport access vlan 2
no ip address
no cdp enable
!
interface GigabitEthernet0
no ip address
no cdp enable
!
interface GigabitEthernet1
description $ETH-WAN$
no ip address
duplex auto
speed auto
pppoe-client dial-pool-number 1
no cdp enable
!
interface Vlan1
ip address 192.168.92.1 255.255.255.0
ip access-group 100 in
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1412
!
interface Vlan2
ip address 192.168.82.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1412
!
interface Dialer0
ip address negotiated
ip mtu 1452
ip nat outside
ip virtual-reassembly in
ip access-group 111 in
ip inspect myfw out
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap pap callin
ppp chap hostname XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx
ppp chap password 0 XXXXXXXXXXXXXXXXXX
ppp pap sent-usernameXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX password 0 XXXXXXXX
!
ip forward-protocol nd
ip http server
ip http access-class 4
ip http authentication local
ip http secure-server
!
!
ip nat inside source list 1 interface Dialer0 overload
ip nat inside source static tcp 192.168.92.10 22 interface Dialer0 22
ip nat inside source static tcp 192.168.92.10 443 interface Dialer0 443
ip nat inside source static tcp 192.168.92.10 5904 interface Dialer0 5904
ip nat inside source static tcp 192.168.92.12 2212 interface Dialer0 2212
ip nat inside source static tcp 192.168.92.13 3389 interface Dialer0 3389
ip nat inside source static tcp 192.168.92.14 8080 interface Dialer0 8080
ip nat inside source list 3 interface Dialer0 overload
ip route 0.0.0.0 0.0.0.0 Dialer0
!
access-list 1 remark CCP_ACL Category=2
access-list 1 permit 192.168.92.0 0.0.0.255
access-list 1 permit 192.168.82.0 0.0.0.255
access-list 2 remark CCP_ACL Category=2
access-list 2 permit 192.168.92.10
access-list 3 permit 192.168.92.12
access-list 3 permit 192.168.92.13
access-list 3 permit 192.168.92.14
access-list 3 remark CCP_ACL Category=2
access-list 3 permit 192.168.92.10
access-list 4 remark Auto generated by SDM Management Access feature
access-list 4 remark CCP_ACL Category=1
access-list 4 permit 192.168.92.0 0.0.0.255
access-list 100 remark Auto generated by SDM Management Access feature
access-list 100 remark CCP_ACL Category=1
access-list 100 permit tcp 192.168.92.0 0.0.0.255 host 192.168.92.1 eq telnet
access-list 100 permit tcp 192.168.92.0 0.0.0.255 host 192.168.92.1 eq 22
access-list 100 permit tcp 192.168.92.0 0.0.0.255 host 192.168.92.1 eq 443
access-list 100 deny tcp any host 192.168.92.1 eq telnet
access-list 100 deny tcp any host 192.168.92.1 eq 22
access-list 100 deny tcp any host 192.168.92.1 eq www
access-list 100 deny tcp any host 192.168.92.1 eq 443
access-list 100 deny tcp any host 192.168.92.1 eq cmd
access-list 100 deny udp any host 192.168.92.1 eq snmp
access-list 100 permit ip any any
access-list 101 remark Auto generated by SDM Management Access feature
access-list 101 remark CCP_ACL Category=1
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
access-list 111 remark Added by EnzephaloN manually
access-list 111 remark CCP_ACL Category=1
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq domain any
access-list 111 permit gre any any
access-list 111 permit tcp any eq 22 host 192.168.92.10 eq 22
access-list 111 permit tcp any eq 443 host 192.168.92.10 eq 443
access-list 111 permit tcp any eq 5904 host 192.168.92.10 eq 5904
access-list 111 permit tcp any eq 2212 host 192.168.92.12 eq 2212
access-list 111 permit tcp any eq 3389 host 192.168.92.13 eq 3389
access-list 111 permit tcp any eq 8080 host 192.168.92.14 eq 8080
access-list 111 deny ip any any
dialer-list 1 protocol ip list 101
mac-address-table aging-time 15
!
snmp-server community public RO
!
line con 0
exec-timeout 0 0
no modem enable
line aux 0
line vty 0 4
access-class 101 in
privilege level 15
password XXXXXXXXXXXXXXXXXXXXXXX
login local
transport input telnet ssh
transport output telnet ssh
!
scheduler allocate 60000 1000
!
endIch würde mich freuen, wenn mir jemand hierbei helfen könnte!
Grüße
Johannes
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 227641
Url: https://administrator.de/forum/cisco-866vae-k9-acl-konfiguration-227641.html
Ausgedruckt am: 31.12.2024 um 10:12 Uhr
20 Kommentare
Neuester Kommentar
Hallo,
alles nach
ist sinnlos.
permit ip any any ist "alles erlauben" und danach folgende ACl's werden gar nicht mehr abgefragt, es ist ja bereits erlaubt...
brammer
alles nach
access-list 100 permit ip any any
ist sinnlos.
permit ip any any ist "alles erlauben" und danach folgende ACl's werden gar nicht mehr abgefragt, es ist ja bereits erlaubt...
brammer
Zitat von @brammer:
> access-list 100 permit ip any any ist sinnlos.
permit ip any any ist "alles erlauben" und danach folgende ACl's werden gar nicht mehr abgefragt, es ist ja bereits
erlaubt...
brammer
> access-list 100 permit ip any any ist sinnlos.
permit ip any any ist "alles erlauben" und danach folgende ACl's werden gar nicht mehr abgefragt, es ist ja bereits
erlaubt...
brammer
Hallo Brammer und danke für Deine Antwort - dazu aber die Frage: bestimmt die Nummer des ACL nicht dessen Device-Zugehörigkeit? Also daß ACL 100 "nur" auf VLAN1 (internes Netzwerk) aktiviert ist? Verstehe ich das falsch?
Johannes
Nein das ist Blödsinn ! Wie immer hilft hier Handbuch lesen oder die Cisco Command Reference als wild zu raten und Halbwahrheiten zu verbreiten !!
ACL Nummer und Device Nummer haben rein gar nichts miteinander zu tun. Der Bereich der ACL Nummerierung bestimmt lediglich ob die ACL eine einfache ACL ist oder eine extended ACL (ab Nummer 100) Der Rest ist vollkommen frei zuortbar in der Konfig.
Eine wasserdichte Beispielkonfiguration beschreibt dir dieses Forumstutorial:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Noch ein Tip: Wenn du statische NAT Zuordnungen nutzt solltest du diese immer aus dem NAT Overload Pool (access-list 101 permit ip 192.168.92.0 0.0.0.255 any ) mit deny entfernen sonst kann es hier mal zu bösen Überraschungen kommen !
Und ja...deine ACLs 2,3,4 usw. sind vollkommen nutzlos, denn sie sind zwar richtig angelegt werden aber auf keinerlei IP Interface angewendet ala "ip access-group 2 in/out". Folglich machen sie auch nix !
ACL Nummer und Device Nummer haben rein gar nichts miteinander zu tun. Der Bereich der ACL Nummerierung bestimmt lediglich ob die ACL eine einfache ACL ist oder eine extended ACL (ab Nummer 100) Der Rest ist vollkommen frei zuortbar in der Konfig.
Eine wasserdichte Beispielkonfiguration beschreibt dir dieses Forumstutorial:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Noch ein Tip: Wenn du statische NAT Zuordnungen nutzt solltest du diese immer aus dem NAT Overload Pool (access-list 101 permit ip 192.168.92.0 0.0.0.255 any ) mit deny entfernen sonst kann es hier mal zu bösen Überraschungen kommen !
Und ja...deine ACLs 2,3,4 usw. sind vollkommen nutzlos, denn sie sind zwar richtig angelegt werden aber auf keinerlei IP Interface angewendet ala "ip access-group 2 in/out". Folglich machen sie auch nix !
Zitat von @aqui:
Nein das ist Blödsinn ! Wie immer hilft hier Handbuch lesen oder die Cisco Command Reference als wild zu raten und
Halbwahrheiten zu verbreiten !!
ACL Nummer und Device Nummer haben rein gar nichts miteinander zu tun. Der Bereich der ACL Nummerierung bestimmt lediglich ob die
ACL eine einfache ACL ist oder eine extended ACL (ab Nummer 100) Der Rest ist vollkommen frei zuortbar in der Konfig.
Nein das ist Blödsinn ! Wie immer hilft hier Handbuch lesen oder die Cisco Command Reference als wild zu raten und
Halbwahrheiten zu verbreiten !!
ACL Nummer und Device Nummer haben rein gar nichts miteinander zu tun. Der Bereich der ACL Nummerierung bestimmt lediglich ob die
ACL eine einfache ACL ist oder eine extended ACL (ab Nummer 100) Der Rest ist vollkommen frei zuortbar in der Konfig.
Hallo aqui
Danke für Deine Antwort und entschuldige bitte meine Vermutung/Frage. Ich wollte mit meiner Frage auf keinen Fall eine Halbwahrheit verbreiten, soweit dies mit einer Frage überhaupt möglich ist. Ich war davon ausgegangen, da die ACL-Nummern ja einem Device zugeordnet werden:
...
interface Dialer0
ip address negotiated
...
ip access-group 111 in
...
...
line vty 0 4
access-class 101 in
...
Eine wasserdichte Beispielkonfiguration beschreibt dir dieses Forumstutorial:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Die habe ich mir mehrmals durchgelesen, doch finde ich in diesem guten Beitrag leider keine Variante mit NAT bzw. Portfordwarding für von außen erreichbar zu machende Dienste (SSH, SSL, Tomcat, etc.). Deswegen war ich so frei und habe hier nochmal nachgefragt.
Noch ein Tip: Wenn du statische NAT Zuordnungen nutzt solltest du diese immer aus dem NAT Overload Pool (access-list 101 permit ip
192.168.92.0 0.0.0.255 any ) mit deny entfernen sonst kann es hier mal zu bösen Überraschungen kommen !
192.168.92.0 0.0.0.255 any ) mit deny entfernen sonst kann es hier mal zu bösen Überraschungen kommen !
Ich versuche mal das umzusetzen von dem Du hier sprichst.
...
ip nat inside source list 101 interface Dialer0 overload
ip nat inside source static tcp 192.168.92.10 22 interface Dialer0 22
ip nat inside source static tcp 192.168.92.10 443 interface Dialer0 443
ip nat inside source static tcp 192.168.92.10 5904 interface Dialer0 5904
ip nat inside source static tcp 192.168.92.12 2212 interface Dialer0 2212
ip nat inside source static tcp 192.168.92.13 3389 interface Dialer0 3389
ip nat inside source static tcp 192.168.92.14 8080 interface Dialer0 8080
!
access-list 23 permit 192.168.92.0 0.0.0.255
access-list 100 remark Auto generated by SDM Management Access feature
access-list 100 remark CCP_ACL Category=1
access-list 100 permit tcp 192.168.92.0 0.0.0.255 host 192.168.92.1 eq telnet
access-list 100 permit tcp 192.168.92.0 0.0.0.255 host 192.168.92.1 eq 22
access-list 100 permit tcp 192.168.92.0 0.0.0.255 host 192.168.92.1 eq 443
access-list 100 deny tcp any host 192.168.92.1 eq telnet
access-list 100 deny tcp any host 192.168.92.1 eq 22
access-list 100 deny tcp any host 192.168.92.1 eq www
access-list 100 deny tcp any host 192.168.92.1 eq 443
access-list 100 deny tcp any host 192.168.92.1 eq cmd
access-list 100 deny udp any host 192.168.92.1 eq snmp
access-list 101 remark Auto generated by SDM Management Access feature
access-list 101 remark CCP_ACL Category=1
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
access-list 101 deny tcp any eq 22 host 192.168.92.10 eq 22
access-list 101 deny tcp any eq 443 host 192.168.92.10 eq 443
access-list 101 deny tcp any eq 5904 host 192.168.92.10 eq 5904
access-list 101 deny tcp any eq 2212 host 192.168.92.12 eq 2212
access-list 101 deny tcp any eq 3389 host 192.168.92.13 eq 3389
access-list 101 deny tcp any eq 8080 host 192.168.92.14 eq 8080
access-list 111 remark Added by EnzephaloN manually
access-list 111 remark CCP_ACL Category=1
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq domain any
access-list 111 permit gre any any
access-list 111 permit tcp any eq 22 host 192.168.92.10 eq 22
access-list 111 permit tcp any eq 443 host 192.168.92.10 eq 443
access-list 111 permit tcp any eq 5904 host 192.168.92.10 eq 5904
access-list 111 permit tcp any eq 2212 host 192.168.92.12 eq 2212
access-list 111 permit tcp any eq 3389 host 192.168.92.13 eq 3389
access-list 111 permit tcp any eq 8080 host 192.168.92.14 eq 8080
access-list 111 deny ip any any
dialer-list 1 protocol ip list 101
...
line vty 0 4
access-class 23 in
privilege level 15
password death666
login local
transport input telnet ssh
transport output telnet ssh
...
Meinst Du das so?
Und ja...deine ACLs 2,3,4 usw. sind vollkommen nutzlos, denn sie sind zwar richtig angelegt werden aber auf keinerlei IP Interface
angewendet ala "ip access-group 2 in/out". Folglich machen sie auch nix !
angewendet ala "ip access-group 2 in/out". Folglich machen sie auch nix !
Okay, dann lösch ich den "Mist" einfach raus. Ebenso habe ich die ACL 1 gelöscht und "ip nat inside source list 1 interface Dialer0 overload" auf "ip nat inside source list 101 interface Dialer0 overload" geändert - ganz nach Deiner Anleitung. Desweiteren habe ich Deine ACL 23 - Konfiguration afu line vty 0 4 übernommen - ich hoffe das ist in meinem Fall auch korrekt?
Kannst Du bitte über die Konfiguration schauen und mir sagen ob das so nun in Ordnung geht, oder ob ich wieder in einen Fehler gerannt bin.
Viele Grüße
Johannes
Hallo Johannes !
OK...mal der Reihe nach.....
Alles was unter "line vty 0 4" an access Parametern steht bezieht sich auf den direkten Zugriff auf den Router selber, sprich sein CLI oder seine GUI. Bezeichnet also den Konfigurationszugriff auf das System selber.
In deiner obigen Konfig gilt jetzt die Access Liste 23, diese erlaubt ausschliesslich eingehenden (in) Zugang aus dem 192.168.92.0er Netz (Absender IP) auf die lokalen IPs des Routers mit den Diensten Telnet und SSH. D.h. die Absender IP muss 192.168.92.x lauten.
Damit ist ein Zugang aus dem Internet quasi ausgeschlossen auf den Router was man ja auch genau will damit kein böser Bube den Router anfasst !!
Da du mit der Firewall arbeitest und CBAC_Accesslisten auf dem Internet Interface (Dialer 0) arbeitest, gilt das erstmal alles, was von Inbound keine gültige Outbound Session hat, eingehend geblockt ist.
Auch das ist ja erstmal gewollt da du keinen haben willst der dir von extern aufs lokale Netzwerk kommt. Zu den Ausnahmen oben kommen wir später....
Zudem verhindert so oder so der NAT Prozess so einen Zugang.
Die Besonderheit ist aber hier die eigentliche WAN IP Adresse (Dialer 0) des Routers, denn die ist immer von dem Firewall Prozess und CBAC ausgeschlossen der nur Sessions aus dem internen LAN nach draußen überwacht. Alles was der Router mit eigener IP sendet muss also über die ACL behandelt werden.
Folglich braucht diese IP besonderen Schutz und das bewerkstelligt die Access Liste 111 die du inbound auf dem Dialer0 Interface aktiviert hast !
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq domain any
access-list 111 permit gre any any
access-list 111 permit tcp any eq 22 host 192.168.92.10 eq 22
access-list 111 permit tcp any eq 443 host 192.168.92.10 eq 443
access-list 111 permit tcp any eq 5904 host 192.168.92.10 eq 5904
access-list 111 permit tcp any eq 2212 host 192.168.92.12 eq 2212
access-list 111 permit tcp any eq 3389 host 192.168.92.13 eq 3389
access-list 111 permit tcp any eq 8080 host 192.168.92.14 eq 8080
access-list 111 deny ip any any
Der Reihe nach macht das folgendes...
Das letzte Statement verbietet alles und den ganzen Rest und macht so den Router dicht !!
Die obigen Regeln ab TCP 22 sind natürlich ziemlicher Murks, sorry !
Wenn du aber nur mal ein klein wenig über die Logik und die IP Paket Kommunikation mit Ziel- und Absender IP nachgedacht hättest, dann wäre dir das schnell selber klar geworden auch ohne Forum.
Die WARUMS der Reihe nach:
Es reicht also wenn du die Dialer0 IP Adresse erreichbar machst für diese Dienste und dann funktioniert dein Szenario auch wie gewünscht !! Als Ziel von remote musst du ja die Dialer0 IP angeben um intern zugreifen zu können !
Richtig muss deine ACL 111 also lauten:
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq domain any
access-list 111 permit gre any any
access-list 111 permit tcp any eq 22 any
access-list 111 permit tcp any eq 443 any
access-list 111 permit tcp any eq 5904 any
access-list 111 permit tcp any eq 2212 any
access-list 111 permit tcp any eq 3389 any
access-list 111 permit tcp any eq 8080 any
access-list 111 deny ip any any
Warum any any ...??
Das any any rührt daher, das du im DSL und der Zwangstrennung des Providers wechselnde IP Adressen am Dialer0 Port hast und das deine Clients auch wechselnde IPs haben je nachdem aus welchem öffentlichen Absendernetz sie zugreifen, deshalb kannst du hier keine feste Host IP angeben ohne zu riskieren das danch nix mehr geht.
Die Ziel IP am Router wechselt also täglich und auch die Absender IPs der remoten Clients.
Bekämest du eine feste Provider IP z.B. 87.10.1.1 dann könnte man in der ACL auch immer diese IP als Ziel IP angeben um die ACL wasserdichter zu machen ala access-list 111 permit tcp any eq 22 host 87.10.1.1
Mit dynamischen Provider IPs geht das aber natürlich nicht.
Sinnvoll wäre hier dann ein DynDNS Eintrag z.B. mit einem no-ip.com Account um immer einen festen Hostnamen für den Zugriff zu haben bei wechselnden IPs.
Das o.a. Tutorial erklärt wie das genau geht !
Solltest du eine feste IP vom Provider bekommen, dann kannst du es natürlich so umsetzen, dann müsstest du aber auch deine "static nat" Statements entsprechend ändern.
Wenn du dir nun deine ACL Konfig mal genau ansiehst dann siehst du das du nur ganze 4 ACLs benutzt (2 für intern 100,101 und 2 für extern 2, 111) auf deinem Router nämlich 23, 100, 101 und 111 !!
Alle anderen ACLs wie die 2,3 usw. sind also überflüssig ! Sie sind zwar angelegt machen aber nichts, da sie keinem aktiven Interface zugeordnet sind. Folglich also überflüssig und du kannst sie auch löschen.
OK, in der korrigierten Version unten hast du das ja auch schon richtigerweise gemacht !
Eine Besonderheit nimmt hier noch die ACL 100 ein die auch wieder Blödsinn ist, sorry.
ACL Statements dort wie :
access-list 100 permit tcp 192.168.92.0 0.0.0.255 host 192.168.92.1 eq telnet
sind wieder völlig unsinnig und machen rein gar nichts !
Warum....?
Das sind doch Pakete die innerhalb des gleichen IP Segments laufen "Alles mit TCP 23 aus dem Netz 192.168.92.0 darf auf den Hoat 192.168.92.1"
Sowas ist unsinnig weil solche Pakete niemals das Router Interface passieren, da sie immer im gleichen IP Netzwerk bleiben und zwischen den beteiligten Hosts direkt im gleichen IP Netz bleiben und somit ja niemals über den Router laufen !! Der hat ja gar nichts zu routen und ist folglich gar nicht involviert !
Die ACL ist damit also eine "Nullnummer" und hat keinerlei Effekt !
Auch die Deny Statements sind unsinnig, da diese ACL nur "inbound" greift also alles was vom Netz kommend in das Router Interface hineinläuft !
Die ACL 100 ist in der obigen Form also überflüssiger und sinnloser Ballast und sollte somit wieder entfernt werden !!
Wenn du verhindern willst das alles externe auf diese Hosts mit diesen Diensten zugreifen kann dann ist
access-list 100 deny tcp any host 192.168.92.1 eq telnet
access-list 100 deny tcp any host 192.168.92.1 eq 22
access-list 100 deny tcp any host 192.168.92.1 eq www
access-list 100 deny tcp any host 192.168.92.1 eq 443
access-list 100 deny tcp any host 192.168.92.1 eq cmd
access-list 100 deny udp any host 192.168.92.1 eq snmp
access-list 100 permit ip any any
richtig !!
Diese ACL müsste dann aber als ip access-group 100 OUT also ausgehend aus dem Router Port IN das Netz konfiguriert sein ! Also von überallher in das lokale .92er Segment.
VORSICHT aber hier:
Wenn du diese ACL so eingibst verhinderst du sämtlichen Zugriff von externen IPs auf die Dienste TCP 22, 80, 443, SNMP usw. !!!
Damt konterkarierst du deine static NAT Statements denn das ist ja ein Portforwarding was dir genau diesen Zugang von remote erlaubt und blockt diese wieder.
Überlege dir also genau WAS du WIE mit der ACL steuern willst und boote dich nicht selber aus !!
Ein heisser Tip zu diesem Thema Remoter Zugang:
Lasse den remoten Zugriff mit simplen Port Forwarding so wie du es machen willst ganz. Das ist immer ein erhebliches Sicherheitsrisiko für die internen, lokalen Rechner, da du ja Löcher in die Router Firewall bohrst und so ungeschützt diesen Traffic intern durchlässt von außen. Zudem kann jeder diesen Traffic ungeschützt mitsniffern von überall.
Wenn du kannst, mach das lieber über ein VPN Zugang wie es auch im 886va Tutorial beschrieben ist. Auch PPTP als VPN ist da noch sicherer als Löcher in der Firewall. PPTP hat jeder Client mit jedem betreibssystem und auch alle Smartphones, iPads usw. im Standard mit an Bord und der Zugriff damit ist allemal stressfreier. Denk drüber nach ! Die Sicherheit deiner Daten sollte dir das allemal wert sein ?!
Gut Port TCP 80 könnte man ausnehmen wenn du intern einen öffentlichen Webserver betreibst. DEN solltest du auf dem 886va dann aber immer in ein separates VLAN setzen quasi als DMZ um ihn vom restlichen lokalen Netz zur Sicherheit abzutrennen. Genug Ports dafür hat der 886va ja allemal.
SO wird wenigstens mit den ACLs ein Schuh draus...!!
Hättest du ja auch immer mit dem Wireshark und dem debug access-list xyz Kommando sofort auf Funktion testen können. Auch "show acces-list xyz" zeigt dir die Hits dieser ACL und damit deren Wirksamkeit.
Mit deinen falschen ACLs müsste der Hitcounter immmer vollständig auf 0 bleiben.
Fazit: Änder die ACL dann kommt das auch alles sofort zum Fliegen !
OK...mal der Reihe nach.....
Alles was unter "line vty 0 4" an access Parametern steht bezieht sich auf den direkten Zugriff auf den Router selber, sprich sein CLI oder seine GUI. Bezeichnet also den Konfigurationszugriff auf das System selber.
In deiner obigen Konfig gilt jetzt die Access Liste 23, diese erlaubt ausschliesslich eingehenden (in) Zugang aus dem 192.168.92.0er Netz (Absender IP) auf die lokalen IPs des Routers mit den Diensten Telnet und SSH. D.h. die Absender IP muss 192.168.92.x lauten.
Damit ist ein Zugang aus dem Internet quasi ausgeschlossen auf den Router was man ja auch genau will damit kein böser Bube den Router anfasst !!
Da du mit der Firewall arbeitest und CBAC_Accesslisten auf dem Internet Interface (Dialer 0) arbeitest, gilt das erstmal alles, was von Inbound keine gültige Outbound Session hat, eingehend geblockt ist.
Auch das ist ja erstmal gewollt da du keinen haben willst der dir von extern aufs lokale Netzwerk kommt. Zu den Ausnahmen oben kommen wir später....
Zudem verhindert so oder so der NAT Prozess so einen Zugang.
Die Besonderheit ist aber hier die eigentliche WAN IP Adresse (Dialer 0) des Routers, denn die ist immer von dem Firewall Prozess und CBAC ausgeschlossen der nur Sessions aus dem internen LAN nach draußen überwacht. Alles was der Router mit eigener IP sendet muss also über die ACL behandelt werden.
Folglich braucht diese IP besonderen Schutz und das bewerkstelligt die Access Liste 111 die du inbound auf dem Dialer0 Interface aktiviert hast !
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq domain any
access-list 111 permit gre any any
access-list 111 permit tcp any eq 22 host 192.168.92.10 eq 22
access-list 111 permit tcp any eq 443 host 192.168.92.10 eq 443
access-list 111 permit tcp any eq 5904 host 192.168.92.10 eq 5904
access-list 111 permit tcp any eq 2212 host 192.168.92.12 eq 2212
access-list 111 permit tcp any eq 3389 host 192.168.92.13 eq 3389
access-list 111 permit tcp any eq 8080 host 192.168.92.14 eq 8080
access-list 111 deny ip any any
Der Reihe nach macht das folgendes...
- Die icmp Statements erlauben eine Reihe von ICMP Steuerungs Paketen die wichtig für die reibungslose TCP Kommunikation sind.
- eq domain erlaubt DNS Pakete inbound auf die Router IP, da der Router selber Proxy DNS ist und mit seiner IP Adresse mit den DNS Servern kommuniziert. (Welche das sind kannst du übrigens auf dem CLI mit "show hosts" sehen !)
- gre erlaubt eingehende GRE Tunnel wenn man eine PPTP VPN Client Einwahl auf dem Router erlaubt für remote User zum VPN Zugriff auf das lokale Netz.
- TCP 22 erlaubt von überallher im Internet (any) den SSH Zugriff auf die 192.168.92.10
- TCP 443 erlaubt von überallher im Internet (any) den HTTPS Zugriff auf die 192.168.92.10
- ...desgleichen der Rest für die anderen Ports
Die obigen Regeln ab TCP 22 sind natürlich ziemlicher Murks, sorry !
Wenn du aber nur mal ein klein wenig über die Logik und die IP Paket Kommunikation mit Ziel- und Absender IP nachgedacht hättest, dann wäre dir das schnell selber klar geworden auch ohne Forum.
Die WARUMS der Reihe nach:
- Als Zieladresse die 192.168.92.10 oder irgend eine andere private_RFC_1918_IP auf dem WAN/Internet Port anzugeben ist dadurch das diese im Internet gar nicht auftauchen natürlich Unsinn, denn jeder Netzwerker weiss das diese IP Adressen im Internet gar nicht geroutet werden !
- Mit deinen static nat xyz Kommandos, die richtig sind, setzt du alles was eingehend auf der WAN / Dialer 0 IP ankommt statisch auf die dort angegebenen internen IPs um. (Kannst du auch mit "show ip nat trans" sehen !)
Es reicht also wenn du die Dialer0 IP Adresse erreichbar machst für diese Dienste und dann funktioniert dein Szenario auch wie gewünscht !! Als Ziel von remote musst du ja die Dialer0 IP angeben um intern zugreifen zu können !
Richtig muss deine ACL 111 also lauten:
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq domain any
access-list 111 permit gre any any
access-list 111 permit tcp any eq 22 any
access-list 111 permit tcp any eq 443 any
access-list 111 permit tcp any eq 5904 any
access-list 111 permit tcp any eq 2212 any
access-list 111 permit tcp any eq 3389 any
access-list 111 permit tcp any eq 8080 any
access-list 111 deny ip any any
Warum any any ...??
Das any any rührt daher, das du im DSL und der Zwangstrennung des Providers wechselnde IP Adressen am Dialer0 Port hast und das deine Clients auch wechselnde IPs haben je nachdem aus welchem öffentlichen Absendernetz sie zugreifen, deshalb kannst du hier keine feste Host IP angeben ohne zu riskieren das danch nix mehr geht.
Die Ziel IP am Router wechselt also täglich und auch die Absender IPs der remoten Clients.
Bekämest du eine feste Provider IP z.B. 87.10.1.1 dann könnte man in der ACL auch immer diese IP als Ziel IP angeben um die ACL wasserdichter zu machen ala access-list 111 permit tcp any eq 22 host 87.10.1.1
Mit dynamischen Provider IPs geht das aber natürlich nicht.
Sinnvoll wäre hier dann ein DynDNS Eintrag z.B. mit einem no-ip.com Account um immer einen festen Hostnamen für den Zugriff zu haben bei wechselnden IPs.
Das o.a. Tutorial erklärt wie das genau geht !
Solltest du eine feste IP vom Provider bekommen, dann kannst du es natürlich so umsetzen, dann müsstest du aber auch deine "static nat" Statements entsprechend ändern.
Wenn du dir nun deine ACL Konfig mal genau ansiehst dann siehst du das du nur ganze 4 ACLs benutzt (2 für intern 100,101 und 2 für extern 2, 111) auf deinem Router nämlich 23, 100, 101 und 111 !!
Alle anderen ACLs wie die 2,3 usw. sind also überflüssig ! Sie sind zwar angelegt machen aber nichts, da sie keinem aktiven Interface zugeordnet sind. Folglich also überflüssig und du kannst sie auch löschen.
OK, in der korrigierten Version unten hast du das ja auch schon richtigerweise gemacht !
Eine Besonderheit nimmt hier noch die ACL 100 ein die auch wieder Blödsinn ist, sorry.
ACL Statements dort wie :
access-list 100 permit tcp 192.168.92.0 0.0.0.255 host 192.168.92.1 eq telnet
sind wieder völlig unsinnig und machen rein gar nichts !
Warum....?
Das sind doch Pakete die innerhalb des gleichen IP Segments laufen "Alles mit TCP 23 aus dem Netz 192.168.92.0 darf auf den Hoat 192.168.92.1"
Sowas ist unsinnig weil solche Pakete niemals das Router Interface passieren, da sie immer im gleichen IP Netzwerk bleiben und zwischen den beteiligten Hosts direkt im gleichen IP Netz bleiben und somit ja niemals über den Router laufen !! Der hat ja gar nichts zu routen und ist folglich gar nicht involviert !
Die ACL ist damit also eine "Nullnummer" und hat keinerlei Effekt !
Auch die Deny Statements sind unsinnig, da diese ACL nur "inbound" greift also alles was vom Netz kommend in das Router Interface hineinläuft !
Die ACL 100 ist in der obigen Form also überflüssiger und sinnloser Ballast und sollte somit wieder entfernt werden !!
Wenn du verhindern willst das alles externe auf diese Hosts mit diesen Diensten zugreifen kann dann ist
access-list 100 deny tcp any host 192.168.92.1 eq telnet
access-list 100 deny tcp any host 192.168.92.1 eq 22
access-list 100 deny tcp any host 192.168.92.1 eq www
access-list 100 deny tcp any host 192.168.92.1 eq 443
access-list 100 deny tcp any host 192.168.92.1 eq cmd
access-list 100 deny udp any host 192.168.92.1 eq snmp
access-list 100 permit ip any any
richtig !!
Diese ACL müsste dann aber als ip access-group 100 OUT also ausgehend aus dem Router Port IN das Netz konfiguriert sein ! Also von überallher in das lokale .92er Segment.
VORSICHT aber hier:
Wenn du diese ACL so eingibst verhinderst du sämtlichen Zugriff von externen IPs auf die Dienste TCP 22, 80, 443, SNMP usw. !!!
Damt konterkarierst du deine static NAT Statements denn das ist ja ein Portforwarding was dir genau diesen Zugang von remote erlaubt und blockt diese wieder.
Überlege dir also genau WAS du WIE mit der ACL steuern willst und boote dich nicht selber aus !!
Ein heisser Tip zu diesem Thema Remoter Zugang:
Lasse den remoten Zugriff mit simplen Port Forwarding so wie du es machen willst ganz. Das ist immer ein erhebliches Sicherheitsrisiko für die internen, lokalen Rechner, da du ja Löcher in die Router Firewall bohrst und so ungeschützt diesen Traffic intern durchlässt von außen. Zudem kann jeder diesen Traffic ungeschützt mitsniffern von überall.
Wenn du kannst, mach das lieber über ein VPN Zugang wie es auch im 886va Tutorial beschrieben ist. Auch PPTP als VPN ist da noch sicherer als Löcher in der Firewall. PPTP hat jeder Client mit jedem betreibssystem und auch alle Smartphones, iPads usw. im Standard mit an Bord und der Zugriff damit ist allemal stressfreier. Denk drüber nach ! Die Sicherheit deiner Daten sollte dir das allemal wert sein ?!
Gut Port TCP 80 könnte man ausnehmen wenn du intern einen öffentlichen Webserver betreibst. DEN solltest du auf dem 886va dann aber immer in ein separates VLAN setzen quasi als DMZ um ihn vom restlichen lokalen Netz zur Sicherheit abzutrennen. Genug Ports dafür hat der 886va ja allemal.
SO wird wenigstens mit den ACLs ein Schuh draus...!!
Hättest du ja auch immer mit dem Wireshark und dem debug access-list xyz Kommando sofort auf Funktion testen können. Auch "show acces-list xyz" zeigt dir die Hits dieser ACL und damit deren Wirksamkeit.
Mit deinen falschen ACLs müsste der Hitcounter immmer vollständig auf 0 bleiben.
Fazit: Änder die ACL dann kommt das auch alles sofort zum Fliegen !
Hallo aqui und schonmal vorweg meinen innigsten Dank für Deine Antworten.
OK...mal der Reihe nach.....
Alles was unter "line vty 0 4" an access Parametern steht bezieht sich auf den direkten Zugriff auf den Router
selber, sprich sein CLI oder seine GUI. Bezeichnet also den Konfigurationszugriff auf das System selber.
In deiner obigen Konfig gilt jetzt die Access Liste 23, diese erlaubt ausschliesslich eingehenden (in) Zugang aus dem
192.168.92.0er Netz (Absender IP) auf die lokalen IPs des Routers mit den Diensten Telnet und SSH. D.h. die Absender IP muss
192.168.92.x lauten.
Damit ist ein Zugang aus dem Internet quasi ausgeschlossen auf den Router was man ja auch genau will damit kein böser Bube
den Router anfasst !!
Alles was unter "line vty 0 4" an access Parametern steht bezieht sich auf den direkten Zugriff auf den Router
selber, sprich sein CLI oder seine GUI. Bezeichnet also den Konfigurationszugriff auf das System selber.
In deiner obigen Konfig gilt jetzt die Access Liste 23, diese erlaubt ausschliesslich eingehenden (in) Zugang aus dem
192.168.92.0er Netz (Absender IP) auf die lokalen IPs des Routers mit den Diensten Telnet und SSH. D.h. die Absender IP muss
192.168.92.x lauten.
Damit ist ein Zugang aus dem Internet quasi ausgeschlossen auf den Router was man ja auch genau will damit kein böser Bube
den Router anfasst !!
Check. Kappiert. Also brauche ich auch das ACL 100 deny-Zeug für 192.168.92.1 garnicht.
Die obigen Regeln ab TCP 22 sind natürlich ziemlicher Murks, sorry !
- Als Zieladresse die 192.168.92.10 oder irgend eine andere private_RFC_1918_IP
na klar- macht Sinn.
* Mit deinen static nat xyz Kommandos, die richtig sind, setzt du alles was eingehend auf der WAN / Dialer 0 IP ankommt
statisch auf die dort angegebenen internen IPs um. (Kannst du auch mit "show ip nat trans" sehen !)
Remote Clients im Internet haben somit also IMMER diese WAN / Dialer0 IP des Routers als Zieladresse, denn DAS ist die IP die
sie ja "sehen" und auch erreichen können...logisch ! Der Router setzt diese dann mit dem statischen NAT Kommando um
auf die interne IP.
Es reicht also wenn du die Dialer0 IP Adresse erreichbar machst für diese Dienste und dann funktioniert dein Szenario auch
wie gewünscht !! Als Ziel von remote musst du ja die Dialer0 IP angeben um intern zugreifen zu können !
Richtig muss deine ACL 111 also lauten:
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq domain any
access-list 111 permit gre any any
access-list 111 permit tcp any eq 22 any
access-list 111 permit tcp any eq 443 any
access-list 111 permit tcp any eq 5904 any
access-list 111 permit tcp any eq 2212 any
access-list 111 permit tcp any eq 3389 any
access-list 111 permit tcp any eq 8080 any
access-list 111 deny ip any any
statisch auf die dort angegebenen internen IPs um. (Kannst du auch mit "show ip nat trans" sehen !)
Remote Clients im Internet haben somit also IMMER diese WAN / Dialer0 IP des Routers als Zieladresse, denn DAS ist die IP die
sie ja "sehen" und auch erreichen können...logisch ! Der Router setzt diese dann mit dem statischen NAT Kommando um
auf die interne IP.
Es reicht also wenn du die Dialer0 IP Adresse erreichbar machst für diese Dienste und dann funktioniert dein Szenario auch
wie gewünscht !! Als Ziel von remote musst du ja die Dialer0 IP angeben um intern zugreifen zu können !
Richtig muss deine ACL 111 also lauten:
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq domain any
access-list 111 permit gre any any
access-list 111 permit tcp any eq 22 any
access-list 111 permit tcp any eq 443 any
access-list 111 permit tcp any eq 5904 any
access-list 111 permit tcp any eq 2212 any
access-list 111 permit tcp any eq 3389 any
access-list 111 permit tcp any eq 8080 any
access-list 111 deny ip any any
Danke! Habe ich so übernommen.
Eine Besonderheit nimmt hier noch die ACL 100 ein die auch wieder Blödsinn ist, sorry.
Die kamen vom beauftragten Techniker, der sich angeblich auf Cisco-Router verstünde - tat er aber wohl nicht wirklich.
ACL Statements dort wie : access-list 100 permit tcp 192.168.92.0 0.0.0.255 host 192.168.92.1 eq telnet
sind wieder völlig unsinnig und machen rein gar nichts !
Warum....?
Das sind doch Pakete die innerhalb des gleichen IP Segments laufen "Alles mit TCP 23 aus dem Netz 192.168.92.0 darf auf den
Hoat 192.168.92.1"
Sowas ist unsinnig weil solche Pakete niemals das Router Interface passieren, da sie immer im gleichen IP Netzwerk bleiben
und zwischen den beteiligten Hosts direkt im gleichen IP Netz bleiben und somit ja niemals über den Router laufen !! Der
hat ja gar nichts zu routen und ist folglich gar nicht involviert !
Die ACL ist damit also eine "Nullnummer" und hat keinerlei Effekt !
Auch die Deny Statements sind unsinnig, da diese ACL nur "inbound" greift also alles was vom Netz kommend in das
Router Interface hineinläuft !
Die ACL 100 ist in der obigen Form also überflüssiger und sinnloser Ballast und sollte somit wieder entfernt werden !!
sind wieder völlig unsinnig und machen rein gar nichts !
Warum....?
Das sind doch Pakete die innerhalb des gleichen IP Segments laufen "Alles mit TCP 23 aus dem Netz 192.168.92.0 darf auf den
Hoat 192.168.92.1"
Sowas ist unsinnig weil solche Pakete niemals das Router Interface passieren, da sie immer im gleichen IP Netzwerk bleiben
und zwischen den beteiligten Hosts direkt im gleichen IP Netz bleiben und somit ja niemals über den Router laufen !! Der
hat ja gar nichts zu routen und ist folglich gar nicht involviert !
Die ACL ist damit also eine "Nullnummer" und hat keinerlei Effekt !
Auch die Deny Statements sind unsinnig, da diese ACL nur "inbound" greift also alles was vom Netz kommend in das
Router Interface hineinläuft !
Die ACL 100 ist in der obigen Form also überflüssiger und sinnloser Ballast und sollte somit wieder entfernt werden !!
Mach ich.
Wenn du verhindern willst das alles externe auf diese Hosts mit diesen Diensten zugreifen kann dann ist
access-list 100 deny tcp any host 192.168.92.1 eq telnet
access-list 100 deny tcp any host 192.168.92.1 eq 22
access-list 100 deny tcp any host 192.168.92.1 eq www
access-list 100 deny tcp any host 192.168.92.1 eq 443
access-list 100 deny tcp any host 192.168.92.1 eq cmd
access-list 100 deny udp any host 192.168.92.1 eq snmp
access-list 100 permit ip any any
richtig !!
Diese ACL müsste dann aber als ip access-group 100 OUT also ausgehend aus dem Router Port IN das Netz konfiguriert sein !
Also von überallher in das lokale .92er Segment.
VORSICHT aber hier:
Wenn du diese ACL so eingibst verhinderst du sämtlichen Zugriff von externen IPs auf die Dienste TCP 22, 80, 443, SNMP usw.
!!!
Damt konterkarierst du deine static NAT Statements denn das ist ja ein Portforwarding was dir genau diesen Zugang von remote
erlaubt und blockt diese wieder.
access-list 100 deny tcp any host 192.168.92.1 eq telnet
access-list 100 deny tcp any host 192.168.92.1 eq 22
access-list 100 deny tcp any host 192.168.92.1 eq www
access-list 100 deny tcp any host 192.168.92.1 eq 443
access-list 100 deny tcp any host 192.168.92.1 eq cmd
access-list 100 deny udp any host 192.168.92.1 eq snmp
access-list 100 permit ip any any
richtig !!
Diese ACL müsste dann aber als ip access-group 100 OUT also ausgehend aus dem Router Port IN das Netz konfiguriert sein !
Also von überallher in das lokale .92er Segment.
VORSICHT aber hier:
Wenn du diese ACL so eingibst verhinderst du sämtlichen Zugriff von externen IPs auf die Dienste TCP 22, 80, 443, SNMP usw.
!!!
Damt konterkarierst du deine static NAT Statements denn das ist ja ein Portforwarding was dir genau diesen Zugang von remote
erlaubt und blockt diese wieder.
Da ich ja ACL 23 habe ist der Zugriff von außen auf den Router nicht möglich. Also brauche ich ACL 100 garnicht. Muß mir also auch keine Sorgen machen, weil ich vorher extra geöffnetes nun wieder hiermit schließen würde. Ich lasse es weg und gut, ja?!
Ein heisser Tip zu diesem Thema Remoter Zugang:
Wenn du kannst, mach das lieber über ein VPN Zugang wie es auch im 886va Tutorial beschrieben ist. Auch PPTP als VPN ist da
noch sicherer als Löcher in der Firewall. PPTP hat jeder Client mit jedem betreibssystem und auch alle Smartphones, iPads
usw. im Standard mit an Bord und der Zugriff damit ist allemal stressfreier. Denk drüber nach ! Die Sicherheit deiner Daten
sollte dir das allemal wert sein ?!
Wenn du kannst, mach das lieber über ein VPN Zugang wie es auch im 886va Tutorial beschrieben ist. Auch PPTP als VPN ist da
noch sicherer als Löcher in der Firewall. PPTP hat jeder Client mit jedem betreibssystem und auch alle Smartphones, iPads
usw. im Standard mit an Bord und der Zugriff damit ist allemal stressfreier. Denk drüber nach ! Die Sicherheit deiner Daten
sollte dir das allemal wert sein ?!
Das wäre jetzt mein nächster Schritt
Fazit: Änder die ACL dann kommt das auch alles sofort zum Fliegen !
Ich fasse also zusammen:
interface GigabitEthernet1
description $ETH-WAN$
no ip address
duplex auto
speed auto
pppoe-client dial-pool-number 1
no cdp enable
!
interface Vlan1
ip address 192.168.92.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1412
!
interface Vlan2
ip address 192.168.82.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1412
!
interface Dialer0
ip address negotiated
ip mtu 1452
ip nat outside
ip virtual-reassembly in
ip access-group 111 in
ip inspect myfw out
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap pap callin
ppp chap hostname XXXXXXXXXXXXXXXXXXXXXXXXX
ppp chap password 0 XXXXXXX
ppp pap sent-username XXXXXXXXXXXXXXXXXXXXX password 0 XXXXXXXXXX
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
!
ip forward-protocol nd
ip http server
ip http access-class 4
ip http authentication local
ip http secure-server
!
!
ip nat inside source list 101 interface Dialer0 overload
ip nat inside source static tcp 192.168.92.10 22 interface Dialer0 22
ip nat inside source static tcp 192.168.92.10 443 interface Dialer0 443
ip nat inside source static tcp 192.168.92.10 5904 interface Dialer0 5904
ip nat inside source static tcp 192.168.92.12 2212 interface Dialer0 2212
ip nat inside source static tcp 192.168.92.13 3389 interface Dialer0 3389
ip nat inside source static tcp 192.168.92.14 8080 interface Dialer0 8080
!
access-list 23 remark ROUTER ACCESS RULES
access-list 23 permit 192.168.92.0 0.0.0.255
access-list 101 remark DIALER 0 IP NAT OVERLOAD RULES
access-list 101 remark CCP_ACL Category=1
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
access-list 101 deny tcp any eq 22 host 192.168.92.10 eq 22
access-list 101 deny tcp any eq 443 host 192.168.92.10 eq 443
access-list 101 deny tcp any eq 5904 host 192.168.92.10 eq 5904
access-list 101 deny tcp any eq 2212 host 192.168.92.12 eq 2212
access-list 101 deny tcp any eq 3389 host 192.168.92.13 eq 3389
access-list 101 deny tcp any eq 8080 host 192.168.92.14 eq 8080
access-list 111 remark DIALER 0 RULES
access-list 111 remark CCP_ACL Category=1
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq domain any
access-list 111 permit gre any any
access-list 111 permit tcp any eq 22 any
access-list 111 permit tcp any eq 443 any
access-list 111 permit tcp any eq 5904 any
access-list 111 permit tcp any eq 2212 any
access-list 111 permit tcp any eq 3389 any
access-list 111 permit tcp any eq 8080 any
access-list 111 deny ip any any
dialer-list 1 protocol ip list 101
mac-address-table aging-time 15
!
snmp-server community public RO
!
line con 0
exec-timeout 0 0
no modem enable
line aux 0
line vty 0 4
access-class 23 in
privilege level 15
password XXXXXXXXXXXXXXX
login local
transport input telnet ssh
transport output telnet ssh
!
Right? Ich hoffe ich habs jetzt
.Und dann fehlt jetzt noch das VPN-Zeugs:
Ich übernehme den Code von Deiner VPN-Konfiguration für Cisco-Router. Aber bei den letzten Zeilen muß ich Dich nochmal dumm fragen, was sie bedeuten, bzw was ich ändern muß. Hier wäre meine Idee dazu:
interface Ethernet 1
description Lokales Ethernet
ip address 192.168.92.254 255.255.255.0
!
ip local pool pptp_dialin 192.168.92.240 192.168.92.250
Ist "Ethernet 1" richtig?
Viele Grüße & Dank.
Johannes
Hi Johannes !
Nach diesem Exkurs weisst du so oder so 100 mal mehr als dieser "Schrauber"....
Zurück zum Thema...
OK, die Konfig ist soweit (fast) richtig, allerdings gibts an der ACL 101 schon wieder was zu meckern. Hier hast du WIEDER den gleichen, schon oben angemahnten Unsinn, verzapft:
access-list 101 deny tcp any eq 22 host 192.168.92.10 eq 22
access-list 101 deny tcp any eq 443 host 192.168.92.10 eq 443
access-list 101 deny tcp any eq 5904 host 192.168.92.10 eq 5904
access-list 101 deny tcp any eq 2212 host 192.168.92.12 eq 2212
access-list 101 deny tcp any eq 3389 host 192.168.92.13 eq 3389
access-list 101 deny tcp any eq 8080 host 192.168.92.14 eq 8080
Das ist die ACL die die Pakete rausfiltert die den PPPoE Prozess zum Provider triggern und damit das PPPoE Dialin. Außerdem bestimmen sie welche Pakete das NAT durchlaufen.
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
ist ja noch richtig.... (Gast WLAN Segment fehlt hier, doch dazu später !)
Das sind alle Pakete die einen Absender IP aus dem 192.168.92.0er Netz, lokales LAN haben und in die Weite Welt sprich Internet gehen.
Die DENY Regeln besagen das alles mit irgendeiner IP und den angegebenen Zielports 22, 443, etc. und Zieladresse des Hosts im 92.er Netz den PPPoE Dialer NICHT triggern.
1.) WO sollen denn andere IPs herkommen ??
2.) Die Ziel IP liegt hier wieder im gleichen lokalen VLAN, sprich diese lokalen Pakete gehen mal wieder NICHT über den Router sondern bleiben lokal...gleiche Story wie oben !
Fazit: Diese Regeln sind wieder sinnfrei...kannst du also auch gleich löschen !
Jetzt fehlt noch dein VLAN 2 in dem das Gast WLAN drin ist. Die sollen doch auch ins Internet oder ??
Damit das auch klappt musst du die ACL 101 noch anpassen wie oben schon angemerkt, die muss dann so aussehen
access-list 101 permit ip 192.168.82.0 0.0.0.255 any
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
Du möchtest aber sicher nicht das deine Gäste auf dein internes .92er Netz und damit deine privaten Daten zugreifen können, oder ??
Ohne eine zusätzlich ACL ist das aber möglich ! Willst du die Gäste von deinem LAN aussperren brauchst du noch eine ACL:
ip access-list extended keingast
deny ip 192.168.82.0 0.0.0.255 192.168.92.0 0.0.0.255 log
permit ip 192.168.82.0 0.0.0.255 any
!
interface Vlan2
description Gast WLAN
ip address 192.168.82.1 255.255.255.0
ip access-group keingast in
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1412
!
Der Rest sieht jetzt soweit OK aus...
Kommen wir zum PPTP VPN Dialin....
Zuerst: Das du Port Forwarding machst von außen UND VPN ist so richtig und gewollt ?? Wenn du das eine machst brauchst du eigentlich das andere nicht, denn ein VPN Client arbeitet so als ob er im lokalen Netzwerk (bei dir VLAN 1) angeschlossen ist.
Mit VPN macht Port Forwarding eigentlich keinen Sinn mehr, denn das VPN soll die Unsicherheit Port Forwarding ja gerade beseitigen !!
Wie gesagt Ausnahme wäre ein lokaler Webhost z.B. der von außen direkt erreichbar sein soll ohne VPN. Ist dem so dann solltest du den aber in ein getrenntes VLAN z.B. VLAN-2 verfrachten und ihn von deinem internen lokalen Netz trennen. Mit entsprechenden ACL kannst du ja von intern auf ihn zugreifen verhinderst aber das die Löcher in der Firewall im internen lokalen Netz liegen (VLAN-1)
OK, deine Entscheidung.....
Nun also die PPTP Konfig Steps (steht aber eigentlich alles auch im 886va Tutorial !!
Das "Ethernet 1" ist natürlich nicht richtig, denn das Template Interface bezieht sich auf dein lokales LAN und dessen Interface ist "vlan 1".
Richtig sieht die PPTP Konfig also so aus:
interface Vlan1
description Lokales LAN
ip address 192.168.92.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1412
!
vpdn enable
!
vpdn-group 1
accept-dialin
protocol pptp
virtual-template 1
!
username vpnbenutzer password test123
!
interface Virtual-Template1
description PPTP Einwahl Interface fuer VPN Zugang
ip unnumbered vlan 1
no keepalive
no cdp enable
peer default ip address pool pptp_dialin
ppp encrypt mppe 128 required
ppp authentication ms-chap-v2
!
ip local pool pptp_dialin 192.168.92.240 192.168.92.250
!
Du musst dafür noch eine ACL Regel in deine ACL 111 einfügen, denn PPTP braucht außer GRE noch TCP 1723:
....
access-list 111 permit gre any any
access-list 111 permit tcp any eq 1723 any
....
Damit klappt dann der PPTP Dialin und auch der Rest.
Weitere PPTP Grundlagen erklärt das Tutorial hier:
VPNs einrichten mit PPTP
Zum Schluss noch ein paar Korrekturen:
Die interne LAN MSS solltest du ändern auf:
ip tcp adjust-mss 1452
und die MTU auf dem Dialer0 Interface in
ip mtu 1492
Auf dem Dialer0 gilt erhöhte Sicherheit deshalb dort
no ip redirects
no ip unreachables
no ip proxy-arp
vom beauftragten Techniker, der sich angeblich auf Cisco-Router verstünde
Oha...nicht mal angeblich sondern der versteht gar nichts !! Den solltest du besser nicht mehr an die Kiste lassen !!Nach diesem Exkurs weisst du so oder so 100 mal mehr als dieser "Schrauber"....
Zurück zum Thema...
OK, die Konfig ist soweit (fast) richtig, allerdings gibts an der ACL 101 schon wieder was zu meckern. Hier hast du WIEDER den gleichen, schon oben angemahnten Unsinn, verzapft:
access-list 101 deny tcp any eq 22 host 192.168.92.10 eq 22
access-list 101 deny tcp any eq 443 host 192.168.92.10 eq 443
access-list 101 deny tcp any eq 5904 host 192.168.92.10 eq 5904
access-list 101 deny tcp any eq 2212 host 192.168.92.12 eq 2212
access-list 101 deny tcp any eq 3389 host 192.168.92.13 eq 3389
access-list 101 deny tcp any eq 8080 host 192.168.92.14 eq 8080
Das ist die ACL die die Pakete rausfiltert die den PPPoE Prozess zum Provider triggern und damit das PPPoE Dialin. Außerdem bestimmen sie welche Pakete das NAT durchlaufen.
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
ist ja noch richtig.... (Gast WLAN Segment fehlt hier, doch dazu später !)
Das sind alle Pakete die einen Absender IP aus dem 192.168.92.0er Netz, lokales LAN haben und in die Weite Welt sprich Internet gehen.
Die DENY Regeln besagen das alles mit irgendeiner IP und den angegebenen Zielports 22, 443, etc. und Zieladresse des Hosts im 92.er Netz den PPPoE Dialer NICHT triggern.
1.) WO sollen denn andere IPs herkommen ??
2.) Die Ziel IP liegt hier wieder im gleichen lokalen VLAN, sprich diese lokalen Pakete gehen mal wieder NICHT über den Router sondern bleiben lokal...gleiche Story wie oben !
Fazit: Diese Regeln sind wieder sinnfrei...kannst du also auch gleich löschen !
Jetzt fehlt noch dein VLAN 2 in dem das Gast WLAN drin ist. Die sollen doch auch ins Internet oder ??
Damit das auch klappt musst du die ACL 101 noch anpassen wie oben schon angemerkt, die muss dann so aussehen
access-list 101 permit ip 192.168.82.0 0.0.0.255 any
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
Du möchtest aber sicher nicht das deine Gäste auf dein internes .92er Netz und damit deine privaten Daten zugreifen können, oder ??
Ohne eine zusätzlich ACL ist das aber möglich ! Willst du die Gäste von deinem LAN aussperren brauchst du noch eine ACL:
ip access-list extended keingast
deny ip 192.168.82.0 0.0.0.255 192.168.92.0 0.0.0.255 log
permit ip 192.168.82.0 0.0.0.255 any
!
interface Vlan2
description Gast WLAN
ip address 192.168.82.1 255.255.255.0
ip access-group keingast in
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1412
!
Der Rest sieht jetzt soweit OK aus...
Kommen wir zum PPTP VPN Dialin....
Zuerst: Das du Port Forwarding machst von außen UND VPN ist so richtig und gewollt ?? Wenn du das eine machst brauchst du eigentlich das andere nicht, denn ein VPN Client arbeitet so als ob er im lokalen Netzwerk (bei dir VLAN 1) angeschlossen ist.
Mit VPN macht Port Forwarding eigentlich keinen Sinn mehr, denn das VPN soll die Unsicherheit Port Forwarding ja gerade beseitigen !!
Wie gesagt Ausnahme wäre ein lokaler Webhost z.B. der von außen direkt erreichbar sein soll ohne VPN. Ist dem so dann solltest du den aber in ein getrenntes VLAN z.B. VLAN-2 verfrachten und ihn von deinem internen lokalen Netz trennen. Mit entsprechenden ACL kannst du ja von intern auf ihn zugreifen verhinderst aber das die Löcher in der Firewall im internen lokalen Netz liegen (VLAN-1)
OK, deine Entscheidung.....
Nun also die PPTP Konfig Steps (steht aber eigentlich alles auch im 886va Tutorial !!
Das "Ethernet 1" ist natürlich nicht richtig, denn das Template Interface bezieht sich auf dein lokales LAN und dessen Interface ist "vlan 1".
Richtig sieht die PPTP Konfig also so aus:
interface Vlan1
description Lokales LAN
ip address 192.168.92.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1412
!
vpdn enable
!
vpdn-group 1
accept-dialin
protocol pptp
virtual-template 1
!
username vpnbenutzer password test123
!
interface Virtual-Template1
description PPTP Einwahl Interface fuer VPN Zugang
ip unnumbered vlan 1
no keepalive
no cdp enable
peer default ip address pool pptp_dialin
ppp encrypt mppe 128 required
ppp authentication ms-chap-v2
!
ip local pool pptp_dialin 192.168.92.240 192.168.92.250
!
Du musst dafür noch eine ACL Regel in deine ACL 111 einfügen, denn PPTP braucht außer GRE noch TCP 1723:
....
access-list 111 permit gre any any
access-list 111 permit tcp any eq 1723 any
....
Damit klappt dann der PPTP Dialin und auch der Rest.
Weitere PPTP Grundlagen erklärt das Tutorial hier:
VPNs einrichten mit PPTP
Zum Schluss noch ein paar Korrekturen:
Die interne LAN MSS solltest du ändern auf:
ip tcp adjust-mss 1452
und die MTU auf dem Dialer0 Interface in
ip mtu 1492
Auf dem Dialer0 gilt erhöhte Sicherheit deshalb dort
no ip redirects
no ip unreachables
no ip proxy-arp
Hallo aqui
Vielen Vielen Dank für Deine Antworten und Deine Geduld. Leider muß ich Letztere noch etwas strapazieren und hoffe auf Dein Verständnis.
access-list 101 permit ip 192.168.82.0 0.0.0.255 any
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
ip access-list extended keingast
deny ip 192.168.82.0 0.0.0.255 192.168.92.0 0.0.0.255 log
permit ip 192.168.82.0 0.0.0.255 any
!
interface Vlan2
description Gast WLAN
ip address 192.168.82.1 255.255.255.0
ip access-group keingast in
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1412
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
ip access-list extended keingast
deny ip 192.168.82.0 0.0.0.255 192.168.92.0 0.0.0.255 log
permit ip 192.168.82.0 0.0.0.255 any
!
interface Vlan2
description Gast WLAN
ip address 192.168.82.1 255.255.255.0
ip access-group keingast in
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1412
Das habe ihc alles so übernommen und der Internetzugang funktioniert und ein grober Test ergab, daß ich aus dem 82er nicht ins 92er komme.
Kommen wir zum PPTP VPN Dialin....
Zuerst: Das du Port Forwarding machst von außen UND VPN ist so richtig und gewollt ?? Wenn du das eine machst brauchst
du eigentlich das andere nicht, denn ein VPN Client arbeitet so als ob er im lokalen Netzwerk (bei dir VLAN 1) angeschlossen ist.
Zuerst: Das du Port Forwarding machst von außen UND VPN ist so richtig und gewollt ?? Wenn du das eine machst brauchst
du eigentlich das andere nicht, denn ein VPN Client arbeitet so als ob er im lokalen Netzwerk (bei dir VLAN 1) angeschlossen ist.
Bis ein gewisser externer Client auf VPN umgeschult ist, muß es paralelle laufen. Danach mach ich das NAT einfach AUS und entferne die ACLs.
interface Vlan1
description Lokales LAN
ip address 192.168.92.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1412
!
vpdn enable
!
vpdn-group 1
accept-dialin
protocol pptp
virtual-template 1
!
username vpnbenutzer password test123
!
interface Virtual-Template1
description PPTP Einwahl Interface fuer VPN Zugang
ip unnumbered vlan 1
no keepalive
no cdp enable
peer default ip address pool pptp_dialin
ppp encrypt mppe 128 required
ppp authentication ms-chap-v2
!
ip local pool pptp_dialin 192.168.92.240 192.168.92.250
!
access-list 111 permit gre any any ## ##red|
access-list 111 permit tcp any eq 1723 any
description Lokales LAN
ip address 192.168.92.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1412
!
vpdn enable
!
vpdn-group 1
accept-dialin
protocol pptp
virtual-template 1
!
username vpnbenutzer password test123
!
interface Virtual-Template1
description PPTP Einwahl Interface fuer VPN Zugang
ip unnumbered vlan 1
no keepalive
no cdp enable
peer default ip address pool pptp_dialin
ppp encrypt mppe 128 required
ppp authentication ms-chap-v2
!
ip local pool pptp_dialin 192.168.92.240 192.168.92.250
!
access-list 111 permit gre any any ## ##red|
access-list 111 permit tcp any eq 1723 any
Habe ich so gemacht. Allerdings kann ich mich nicht auf den Server verbinden. Mein Smartphone sagt "nicht erfolgreich".
Zum Schluss noch ein paar Korrekturen:
ip tcp adjust-mss 1452
ip mtu 1492
no ip redirects
no ip unreachables
no ip proxy-arp
ip tcp adjust-mss 1452
ip mtu 1492
no ip redirects
no ip unreachables
no ip proxy-arp
Habe ich geändert.
Gravierender aber als daß das VPN noch nicht geht - das NAT geht nicht. Also ich kann von außen nicht auf die dahinterliegenden Server zugreifen. Weder RDP noch SSH will klappen.
Hier nochmal zum Abgleichen meine Konfig (ohne VPN)
Building configuration...
Current configuration : 6529 bytes
!
! Last configuration change at 12:39:05 UTC Sun Jan 26 2014 by root
version 15.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
!
no logging buffered
enable secret 5 XXXXXXXXXXXXXXXXXXXXXXXX
enable password XXXXXXXXXXX
!
no aaa new-model
no process cpu extended history
no process cpu autoprofile hog
wan mode ethernet
!
!
!
ip dhcp excluded-address 192.168.92.1 192.168.92.129
ip dhcp excluded-address 192.168.92.200 192.168.92.254
ip dhcp excluded-address 192.168.82.1 192.168.82.129
ip dhcp excluded-address 192.168.82.200 192.168.82.254
!
ip dhcp pool standard
import all
network 192.168.92.0 255.255.255.0
dns-server 192.168.92.1 8.8.8.8
default-router 192.168.92.1
!
ip dhcp pool gastwlan
network 192.168.82.0 255.255.255.0
dns-server 192.168.82.1 8.8.8.8
default-router 192.168.82.1
!
!
!
ip inspect name myfw udp
ip inspect name myfw tcp
ip cef
no ipv6 cef
!
!
vpdn enable
!
vpdn-group 1
!
!
!
crypto pki trustpoint TP-self-signed-1437846337
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-1437846337
revocation-check none
rsakeypair TP-self-signed-1437846337
!
!
crypto pki certificate chain TP-self-signed-1437846337
certificate self-signed 01
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
quit
!
!
username XXXXX privilege 15 secret 4 XXXXXXXXXXXXXXXX
!
!
controller VDSL 0
shutdown
!
no ip ftp passive
!
!
!
!
!
!
!
!
!
!
!
!
interface ATM0
no ip address
shutdown
no atm ilmi-keepalive
!
interface Ethernet0
no ip address
shutdown
no cdp enable
!
interface FastEthernet0
no ip address
shutdown
no cdp enable
!
interface FastEthernet1
no ip address
shutdown
no cdp enable
!
interface FastEthernet2
no ip address
shutdown
no cdp enable
!
interface FastEthernet3
switchport access vlan 2
no ip address
no cdp enable
!
interface GigabitEthernet0
no ip address
no cdp enable
!
interface GigabitEthernet1
description $ETH-WAN$
no ip address
duplex auto
speed auto
pppoe-client dial-pool-number 1
no cdp enable
!
interface Vlan1
ip address 192.168.92.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
interface Vlan2
description GastWLan
ip address 192.168.82.1 255.255.255.0
ip access-group keingast in
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
interface Dialer0
ip address negotiated
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip inspect myfw out
ip nat outside
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap pap callin
ppp chap hostname XXXXXXXXXXXXXXXX
ppp chap password 0 XXXXXXXXX
ppp pap sent-username XXXXXXXXXXXXXXXXXXXXXX password 0 XXXXXXXXXXXXXX
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
!
ip forward-protocol nd
ip http server
ip http access-class 4
ip http authentication local
ip http secure-server
!
!
ip nat inside source static tcp 192.168.92.10 22 interface Dialer0 22
ip nat inside source static tcp 192.168.92.10 443 interface Dialer0 443
ip nat inside source static tcp 192.168.92.10 5904 interface Dialer0 5904
ip nat inside source static tcp 192.168.92.12 2212 interface Dialer0 2212
ip nat inside source static tcp 192.168.92.13 3389 interface Dialer0 3389
ip nat inside source static tcp 192.168.92.14 8080 interface Dialer0 8080
ip nat inside source list 101 interface Dialer0 overload
!
ip access-list extended keingast
deny ip 192.168.82.0 0.0.0.255 192.168.92.0 0.0.0.255
permit ip 192.168.82.0 0.0.0.255 any
remark CCP_ACL Category=1
!
access-list 4 remark Auto generated by SDM Management Access feature
access-list 4 remark CCP_ACL Category=1
access-list 4 permit 192.168.92.0 0.0.0.255
access-list 101 remark Auto generated by SDM Management Access feature
access-list 101 remark CCP_ACL Category=3
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
access-list 101 permit ip 192.168.82.0 0.0.0.255 any
access-list 111 remark CCP_ACL Category=1
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq domain any
access-list 111 permit gre any any
access-list 111 remark VPN
access-list 111 permit tcp any eq 1723 any
access-list 111 permit tcp any eq 22 any
access-list 111 permit tcp any eq 443 any
access-list 111 permit tcp any eq 5904 any
access-list 111 permit tcp any eq 2212 any
access-list 111 permit tcp any eq 3389 any
access-list 111 permit tcp any eq 8080 any
access-list 111 deny ip any any
dialer-list 1 protocol ip list 101
mac-address-table aging-time 15
no cdp run
!
snmp-server community public RO
!
line con 0
exec-timeout 0 0
no modem enable
line aux 0
line vty 0 4
access-class 4 in
privilege level 15
password XXXXXXXXX
login local
transport input telnet ssh
transport output telnet ssh
!
scheduler allocate 60000 1000
!
end
Wenn ich das so lese, dann müsste das doch gehen. Ich habe die Weiterleitungen der Ports auf den entsprechenden Server und in der Firewall mache ich per ACL 111 die Ports nach außen auf. Aber trotzdem kann ich nicht auf die Ports von außen verbinden... (nebenbei entfällt so daß Konfigurieren des Routers vom Sofa
).Siehst Du den Fehler?
Viele Grüße
Johannes
OK erstmal der Reihe nach....
Thema PPTP
Bedenke das das Smartphone in einem externen Netz sein MUSS ! Es darf nicht irgendwie per WLAN in einem der internen Netze sein !
Die Ziel IP des PPTP Clients auf dem Smartphone ist die Dialer0 IP Adresse also die WAN IP des Routers ! Vergiss das nicht !
Welche das ist kannst du mit dem Kommando sh ip int brief sehen !
2ter wichtiger Punkt: Dein Smartphone Vertrag darf KEIN billiger nur Surf Vertrag sein wo du vom Provider eine private RFC 1918 IP Adresse auf dem Smartphone bekommst. Dann macht der Mobilprovider selber NAT und das ist dann das AUS für das PPTP VPN denn das kann das provider NAT nicht überwinden.
Checke also zuallererst wenn du im Mobilfunknetz des Providers bist WAS für eine IP Adresse du bekommen hast dort ! Das darf keine 10er, 172.16-32. oder 192.168er sein !
Am besten debuggst du mal PPTP mit dem "debug ip pptp" Kommando und checkst mal ob PPTP Pakete überhaupt am Router ankommen !
Denk dran wenn du per Telnet drauf bist musst du "term mon" eingeben sonst siehst du die Debug Konsol Messages nicht !
WICHTIG: Nach dem Debuggen immer u all eingeben um das Debugging auszuschalten !
Damit solltest du das schnell troubleshooten können. Die Konfig ist soweit OK dafür.
Thema NAT:
Port 22, 80 und 443 ist problematisch, da der Router diese Ports selber hält. Leider hast du diese auch aktiviert. Es macht also mal Sinn den HTTP und HTTPS Server mit "no ip http..." abzuschalten um diese mögliche Fehlerquelle auszuschliessen.
Alternativ reicht es wenn du nur mal mit RDP TCP 3389 oder TCP 8080 probierst denn das spricht der Router de facto nicht !
Die Konfig ist soweit richtig.
Problem ist die NAT Overload ACL, denn du hast nun 2 NAT Prozesse die die Hosts .10., .12, .13 und .14 verwenden, was zu Problemen führt, denn für die hast du ja einen feste statische NAT Beziehung !
Du musst also diese Hosts aus der 101er ACL entfernen am Anfang mit
access-list 101 deny ip host 192.168.92.10 any
access-list 101 deny ip host 192.168.92.12 any
access-list 101 deny ip host 192.168.92.13 any
access-list 101 deny ip host 192.168.92.14 any
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
access-list 101 permit ip 192.168.82.0 0.0.0.255 any
Damit gilt dann nur die statische Zuweisung für diese Hosts. Allerdings wird das NAT nach draußen dann rein auf diese TCP Dienste beschränkt und nichts anderes.
Willst du das nicht musst du einen volles NAT aller Ports machen ala:
ip nat inside source static 192.168.92.10 interface Dialer0
für alle diese Hosts. Da musst du dich dann entscheiden.
Auch hier hilft immer ein debuggen des IP NAT Prozess mit dem Debugger !
Dort siehst du dann genau wo es kneift. Cisco hat dazu auch eine gute Doku:
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186 ...
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_ ...
Bzw. hier in der Kombination Dynamisch und statisch:
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186 ...
Was nch wichtig ist: Bei dem Zugriff so per Port Forwarding (static NAT) von außen kommst du an den internen Hosts immer mit einer EXTERNEN IP Absender Adresse an, vergiss das nicht !
In der Regel blocken loakle Firewalls auf den Endgeräten wie Windows solche Pakete im Default !
Du musst also zwingend die lokale Firewall der Hosts anpassen das die diese Pakete akzeptieren. Alternativ die Firewall mal temporär deaktivieren um sich damit nicht selber ein Bein zu stellen.
Hilfreich ist immer ein Wireshark auf solchem PC und mal mitzusniffern ob diese externen Pakete dort ankommen !
Thema PPTP
Allerdings kann ich mich nicht auf den Server verbinden. Mein Smartphone sagt "nicht erfolgreich".
Von WO verbindest du dich mit dem Smartphone ?Bedenke das das Smartphone in einem externen Netz sein MUSS ! Es darf nicht irgendwie per WLAN in einem der internen Netze sein !
Die Ziel IP des PPTP Clients auf dem Smartphone ist die Dialer0 IP Adresse also die WAN IP des Routers ! Vergiss das nicht !
Welche das ist kannst du mit dem Kommando sh ip int brief sehen !
2ter wichtiger Punkt: Dein Smartphone Vertrag darf KEIN billiger nur Surf Vertrag sein wo du vom Provider eine private RFC 1918 IP Adresse auf dem Smartphone bekommst. Dann macht der Mobilprovider selber NAT und das ist dann das AUS für das PPTP VPN denn das kann das provider NAT nicht überwinden.
Checke also zuallererst wenn du im Mobilfunknetz des Providers bist WAS für eine IP Adresse du bekommen hast dort ! Das darf keine 10er, 172.16-32. oder 192.168er sein !
Am besten debuggst du mal PPTP mit dem "debug ip pptp" Kommando und checkst mal ob PPTP Pakete überhaupt am Router ankommen !
Denk dran wenn du per Telnet drauf bist musst du "term mon" eingeben sonst siehst du die Debug Konsol Messages nicht !
WICHTIG: Nach dem Debuggen immer u all eingeben um das Debugging auszuschalten !
Damit solltest du das schnell troubleshooten können. Die Konfig ist soweit OK dafür.
Thema NAT:
Port 22, 80 und 443 ist problematisch, da der Router diese Ports selber hält. Leider hast du diese auch aktiviert. Es macht also mal Sinn den HTTP und HTTPS Server mit "no ip http..." abzuschalten um diese mögliche Fehlerquelle auszuschliessen.
Alternativ reicht es wenn du nur mal mit RDP TCP 3389 oder TCP 8080 probierst denn das spricht der Router de facto nicht !
Die Konfig ist soweit richtig.
Problem ist die NAT Overload ACL, denn du hast nun 2 NAT Prozesse die die Hosts .10., .12, .13 und .14 verwenden, was zu Problemen führt, denn für die hast du ja einen feste statische NAT Beziehung !
Du musst also diese Hosts aus der 101er ACL entfernen am Anfang mit
access-list 101 deny ip host 192.168.92.10 any
access-list 101 deny ip host 192.168.92.12 any
access-list 101 deny ip host 192.168.92.13 any
access-list 101 deny ip host 192.168.92.14 any
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
access-list 101 permit ip 192.168.82.0 0.0.0.255 any
Damit gilt dann nur die statische Zuweisung für diese Hosts. Allerdings wird das NAT nach draußen dann rein auf diese TCP Dienste beschränkt und nichts anderes.
Willst du das nicht musst du einen volles NAT aller Ports machen ala:
ip nat inside source static 192.168.92.10 interface Dialer0
für alle diese Hosts. Da musst du dich dann entscheiden.
Auch hier hilft immer ein debuggen des IP NAT Prozess mit dem Debugger !
Dort siehst du dann genau wo es kneift. Cisco hat dazu auch eine gute Doku:
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186 ...
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_ ...
Bzw. hier in der Kombination Dynamisch und statisch:
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186 ...
Was nch wichtig ist: Bei dem Zugriff so per Port Forwarding (static NAT) von außen kommst du an den internen Hosts immer mit einer EXTERNEN IP Absender Adresse an, vergiss das nicht !
In der Regel blocken loakle Firewalls auf den Endgeräten wie Windows solche Pakete im Default !
Du musst also zwingend die lokale Firewall der Hosts anpassen das die diese Pakete akzeptieren. Alternativ die Firewall mal temporär deaktivieren um sich damit nicht selber ein Bein zu stellen.
Hilfreich ist immer ein Wireshark auf solchem PC und mal mitzusniffern ob diese externen Pakete dort ankommen !
Hallo aqui
Ja, war per HSPA im Internet. Habe mit der Dyn-Adresse auf das Netzwerk zugreifen wollen.
. Aber: Ich bin nun wieder zuhause und habe es von dort mit einem Rechner probiert auf das Netzwerk zuzugreifen. Auch das war ohne Erfolg - ich konnte keine Verbindung herstellen. Es liegt also nicht am www-Zugang des Clients, sondern irgendwie am Router.
.
Was mich noch vorhin irritiert hat. Ich habe auf einem Rechner in dem Netzwerk auch das CiscoConfigurationProfessional installiert. Dort steht unter "firewall", daß diese inaktiv wäre: "IOS Firewall inaktiv für Dialer0."
Ich vermute ja, daß irgendwas an den NAT-Einstellungen nicht passt. Ich habe nämlich mal "access-list 1111 deny ip any any" testweise entfernt - das sollte ja "alles durchlassen". Aber auch dann funktionierte der Fernzugriff leider nicht.
Ich werde das morgen mit den ACL101-Einträgen probieren - mal sehen ob das den Fehler schon behebt.
Viele Grüße
Johannes
Ja, war per HSPA im Internet. Habe mit der Dyn-Adresse auf das Netzwerk zugreifen wollen.
2ter wichtiger Punkt: Dein Smartphone Vertrag darf KEIN billiger nur Surf Vertrag sein wo du vom Provider eine private RFC
1918 IP Adresse auf dem Smartphone bekommst. Dann macht der Mobilprovider selber NAT und das ist dann das AUS für das PPTP
VPN denn das kann das provider NAT nicht überwinden.
Ist ein "ordentliches" HSPA 1918 IP Adresse auf dem Smartphone bekommst. Dann macht der Mobilprovider selber NAT und das ist dann das AUS für das PPTP
VPN denn das kann das provider NAT nicht überwinden.
. Aber: Ich bin nun wieder zuhause und habe es von dort mit einem Rechner probiert auf das Netzwerk zuzugreifen. Auch das war ohne Erfolg - ich konnte keine Verbindung herstellen. Es liegt also nicht am www-Zugang des Clients, sondern irgendwie am Router.Am besten debuggst du mal PPTP mit dem "debug ip pptp" Kommando und checkst mal ob PPTP Pakete überhaupt am Router
ankommen !
Denk dran wenn du per Telnet drauf bist musst du "term mon" eingeben sonst siehst du die Debug Konsol Messages nicht !
WICHTIG: Nach dem Debuggen immer u all eingeben um das Debugging auszuschalten !
Damit solltest du das schnell troubleshooten können. Die Konfig ist soweit OK dafür.
Werde ich probieren, wenn ich mal wieder vor Ort bin. Kann ja leider nicht mehr remote am Router arbeiten.ankommen !
Denk dran wenn du per Telnet drauf bist musst du "term mon" eingeben sonst siehst du die Debug Konsol Messages nicht !
WICHTIG: Nach dem Debuggen immer u all eingeben um das Debugging auszuschalten !
Damit solltest du das schnell troubleshooten können. Die Konfig ist soweit OK dafür.
Thema NAT:
Port 22, 80 und 443 ist problematisch, da der Router diese Ports selber hält. Leider hast du diese auch aktiviert. Es macht
also mal Sinn den HTTP und HTTPS Server mit "no ip http..." abzuschalten um diese mögliche Fehlerquelle
auszuschliessen.
Kann ich noch machen. Das Webinterface kann man eh nicht gebrauchen... aber...Port 22, 80 und 443 ist problematisch, da der Router diese Ports selber hält. Leider hast du diese auch aktiviert. Es macht
also mal Sinn den HTTP und HTTPS Server mit "no ip http..." abzuschalten um diese mögliche Fehlerquelle
auszuschliessen.
Alternativ reicht es wenn du nur mal mit RDP TCP 3389 oder TCP 8080 probierst denn das spricht der Router de facto nicht !
Die Konfig ist soweit richtig.
Aber es geht leider nicht! Ich habe RDP und SSH vom Smartphone (via HSPA) zu den Servern versucht. Ging früher immer, nun nicht mehr Die Konfig ist soweit richtig.
.Problem ist die NAT Overload ACL, denn du hast nun 2 NAT Prozesse die die Hosts .10., .12, .13 und .14 verwenden, was zu Problemen
führt, denn für die hast du ja einen feste statische NAT Beziehung !
Du musst also diese Hosts aus der 101er ACL entfernen am Anfang mit access-list 101 deny ip host 192.168.92.10 any
access-list 101 deny ip host 192.168.92.12 any
access-list 101 deny ip host 192.168.92.13 any
access-list 101 deny ip host 192.168.92.14 any
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
access-list 101 permit ip 192.168.82.0 0.0.0.255 any
Werde ich hinzufügen - kanns dadurch vielleicht wieder funktionieren?führt, denn für die hast du ja einen feste statische NAT Beziehung !
Du musst also diese Hosts aus der 101er ACL entfernen am Anfang mit access-list 101 deny ip host 192.168.92.10 any
access-list 101 deny ip host 192.168.92.12 any
access-list 101 deny ip host 192.168.92.13 any
access-list 101 deny ip host 192.168.92.14 any
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
access-list 101 permit ip 192.168.82.0 0.0.0.255 any
Was noch wichtig ist: Bei dem Zugriff so per Port Forwarding (static NAT) von außen kommst du an den internen Hosts immer mit
einer EXTERNEN IP Absender Adresse an, vergiss das nicht !
In der Regel blocken loakle Firewalls auf den Endgeräten wie Windows solche Pakete im Default !
Hat vorher mit anderem Router funktioniert - sollte jetzt auch funktionieren. Der Fernzugriff funktionierte ja, bis ich "Deine" Konfiguration gestern abend eingespielt habe.einer EXTERNEN IP Absender Adresse an, vergiss das nicht !
In der Regel blocken loakle Firewalls auf den Endgeräten wie Windows solche Pakete im Default !
Was mich noch vorhin irritiert hat. Ich habe auf einem Rechner in dem Netzwerk auch das CiscoConfigurationProfessional installiert. Dort steht unter "firewall", daß diese inaktiv wäre: "IOS Firewall inaktiv für Dialer0."
Ich vermute ja, daß irgendwas an den NAT-Einstellungen nicht passt. Ich habe nämlich mal "access-list 1111 deny ip any any" testweise entfernt - das sollte ja "alles durchlassen". Aber auch dann funktionierte der Fernzugriff leider nicht.
Ich werde das morgen mit den ACL101-Einträgen probieren - mal sehen ob das den Fehler schon behebt.
Viele Grüße
Johannes
Dort steht unter "firewall", daß diese inaktiv wäre: "IOS Firewall inaktiv für Dialer0."
Mmmmhhh... das kann ja nicht sein denn unter dem Dialer0 steht ja ganz klar:ip inspect myfw out
Da lügt das Tool also. Man sollte immer vorsichtig sein was diese ominösen Tools ausgeben und sich lieber auf das verlassen was die CLI aussagt. Du weisst doch "Real networkers don't click !"
Die Aussage
Der Fernzugriff funktionierte ja, bis ich "Deine" Konfiguration gestern abend eingespielt habe.
verwirrt jetzt etwas. Hast du noch die Dialer0 Konfig der Version wo das funktionierte, das wäre mal interessant ?!WAS war da anders als zur aktuellen Konfig ??
Hallo Johannes !
Zuerst ein Wort der Entschulgigung. Riesen Denkfehler bei der ACL... war aber wohl der Stress....
Die ACL "access-list 111 permit tcp any eq 443 any" war total falsch !! Warum...??
Das erlaubt alles mit dem Absender Port TCP 443. Das ist natürlich Unsinn, denn der Absender Port ist Random und der Zielport muss es natürlich sein.
Ich war da geistig etwas abwesend...sorry. Richtig (und getestet) lautet die 111er ACL also
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq domain any
access-list 111 permit gre any any
access-list 111 permit tcp any any eq 1723
access-list 111 permit tcp any any eq 22
access-list 111 permit tcp any any eq 443
access-list 111 permit tcp any any eq 5904
access-list 111 permit tcp any any eq 2212
access-list 111 permit tcp any any eq 3389
access-list 111 permit tcp any any eq 8080
access-list 111 deny ip any any
In einem Laboraufbau ist das nochmal wasserdicht geprüft:
(Internet Client 10.10.10.1)=====(eth1-Cisco800-eth0)======(lokaler Host 192.168.1.163)
Labor Konfig: (Überflüssiges entfernt)
clock timezone CET 1
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
ip inspect name myfw udp
ip inspect name myfw tcp
!
vpdn enable
!
vpdn-group 1
accept-dialin
protocol pptp
virtual-template 1
!
username vpn password 0 test123
!
interface Ethernet0
ip address 192.168.1.163 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface Ethernet1
ip address 10.10.10.254 255.255.255.0
ip access-group 111 in
ip nat outside
ip inspect myfw out
ip virtual-reassembly
duplex auto
!
interface Virtual-Template1
description PPTP Einwahl Interface fuer VPN Zugang
ip unnumbered Ethernet0
peer default ip address pool pptp_dialin
no keepalive
ppp encrypt mppe 128 required
ppp authentication ms-chap-v2
!
ip local pool pptp_dialin 192.168.1.207 192.168.1.210
ip forward-protocol nd
!
ip nat inside source list 101 interface Ethernet1 overload
ip nat inside source static tcp 192.168.1.166 80 interface Ethernet1 80
ip nat inside source static tcp 192.168.1.166 23 interface Ethernet1 52323
!
access-list 101 permit ip 192.168.1.0 0.0.0.255 any
access-list 111 permit gre any any
access-list 111 permit tcp any any eq 1723
access-list 111 permit tcp any any eq www
access-list 111 permit tcp any any eq 52323 log
access-list 111 deny ip any any log
!
end
Hier kannst du das nochmal genau sehen mit der "falschen" ACL wenn man das logging mitlaufen lässt und den Zugriff versucht:
Jan 27 16:32:09.195: %SEC-6-IPACCESSLOGP: list 111 denied tcp 10.10.10.1(1288) -> 10.10.10.254(52323), 2 packets cc
Absenderport TCP 1288 und Zielport ist TCP 52323. Letzteren testweise um zu sehen ob Port Translation zwingend erforderlich ist wenn der Router selber auf diese Ports hört.
Auch hier lautet die Antwort NEIN. Das geht wunderbar mit den Standardports.
Mit der richtigen ACL dann die Bestätigung:
Jan 27 16:35:34.611: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 10.10.10.1(1289) -> 10.10.10.254(52323), 1 packet
Erlaubt da TCP 52323 !
Jan 27 16:36:19.743: %SEC-6-IPACCESSLOGP: list 111 denied tcp 10.10.10.1(1290) -> 10.10.10.254(23), 1 packet
Verboten da TCP 23 nicht erlaubt.
Hier siehst du einen Output der statischne Translation für den remote Port Forwarding Zugriff auf den Webserver an .1.166
cisco#sh ip nat trans
Pro Inside global Inside local Outside local Outside global
tcp 10.10.10.254:52323 192.168.7.166:23 --- ---
tcp 10.10.10.254:80 192.168.1.166:80 10.10.10.1:1272 10.10.10.1:1272
tcp 10.10.10.254:80 192.168.1.166:80 10.10.10.1:1273 10.10.10.1:1273
tcp 10.10.10.254:80 192.168.1.166:80 10.10.10.1:1274 10.10.10.1:1274
tcp 10.10.10.254:80 192.168.1.166:80 10.10.10.1:1275 10.10.10.1:1275
tcp 10.10.10.254:80 192.168.1.166:80 10.10.10.1:1276 10.10.10.1:1276
tcp 10.10.10.254:80 192.168.1.166:80 --- ---
Desgleichen der Beweis für das funktionierende PPTP VPN Dialin:
#debug ppp authentication
PPP authentication debugging is on
cisco#
Jan 27 16:24:28.207: ppp2 PPP: Using vpn set call direction
Jan 27 16:24:28.207: ppp2 PPP: Treating connection as a callin
Jan 27 16:24:28.207: ppp2 PPP: Session handle[3F000006] Session id[2]
Jan 27 16:24:28.223: ppp2 PPP: Authorization required
Jan 27 16:24:28.235: ppp2 MS-CHAP-V2: O CHALLENGE id 1 len 33 from "cisco"
Jan 27 16:24:28.243: ppp2 MS-CHAP-V2: I RESPONSE id 1 len 57 from "vpn"
Jan 27 16:24:28.243: ppp2 PPP: Sent MSCHAP_V2 LOGIN Request
Jan 27 16:24:28.283: ppp2 PPP: Received LOGIN Response PASS
Jan 27 16:24:28.291: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up
Jan 27 16:24:28.295: Vi3 PPP: Sent LCP AUTHOR Request
Jan 27 16:24:28.295: Vi3 PPP: Sent IPCP AUTHOR Request
Jan 27 16:24:28.295: Vi3 LCP: Received AAA AUTHOR Response PASS
Jan 27 16:24:28.299: Vi3 IPCP: Received AAA AUTHOR Response PASS
Jan 27 16:24:28.299: Vi3 MS-CHAP-V2: O SUCCESS id 1 len 46 msg is "S=0C0363C3D5E1CE9E1A9D5D5BD66C5EDADCFDDCE8"
Jan 27 16:24:28.303: Vi3 PPP: Sent CCP AUTHOR Request
Jan 27 16:24:28.307: Vi3 CCP: Received AAA AUTHOR Response PASS
Jan 27 16:24:29.291: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up
Fazit: Alles ist gut !! Änder die ACL 111 in die korrigierte Form und dann kommt alles zum Fliegen wie es soll !
Sorry nochmal für die Irreführung aber das passiert in der Hektik mal
Zuerst ein Wort der Entschulgigung. Riesen Denkfehler bei der ACL...
war aber wohl der Stress....Die ACL "access-list 111 permit tcp any eq 443 any" war total falsch !! Warum...??
Das erlaubt alles mit dem Absender Port TCP 443. Das ist natürlich Unsinn, denn der Absender Port ist Random und der Zielport muss es natürlich sein.
Ich war da geistig etwas abwesend...sorry. Richtig (und getestet) lautet die 111er ACL also
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq domain any
access-list 111 permit gre any any
access-list 111 permit tcp any any eq 1723
access-list 111 permit tcp any any eq 22
access-list 111 permit tcp any any eq 443
access-list 111 permit tcp any any eq 5904
access-list 111 permit tcp any any eq 2212
access-list 111 permit tcp any any eq 3389
access-list 111 permit tcp any any eq 8080
access-list 111 deny ip any any
In einem Laboraufbau ist das nochmal wasserdicht geprüft:
(Internet Client 10.10.10.1)=====(eth1-Cisco800-eth0)======(lokaler Host 192.168.1.163)
Labor Konfig: (Überflüssiges entfernt)
clock timezone CET 1
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
ip inspect name myfw udp
ip inspect name myfw tcp
!
vpdn enable
!
vpdn-group 1
accept-dialin
protocol pptp
virtual-template 1
!
username vpn password 0 test123
!
interface Ethernet0
ip address 192.168.1.163 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface Ethernet1
ip address 10.10.10.254 255.255.255.0
ip access-group 111 in
ip nat outside
ip inspect myfw out
ip virtual-reassembly
duplex auto
!
interface Virtual-Template1
description PPTP Einwahl Interface fuer VPN Zugang
ip unnumbered Ethernet0
peer default ip address pool pptp_dialin
no keepalive
ppp encrypt mppe 128 required
ppp authentication ms-chap-v2
!
ip local pool pptp_dialin 192.168.1.207 192.168.1.210
ip forward-protocol nd
!
ip nat inside source list 101 interface Ethernet1 overload
ip nat inside source static tcp 192.168.1.166 80 interface Ethernet1 80
ip nat inside source static tcp 192.168.1.166 23 interface Ethernet1 52323
!
access-list 101 permit ip 192.168.1.0 0.0.0.255 any
access-list 111 permit gre any any
access-list 111 permit tcp any any eq 1723
access-list 111 permit tcp any any eq www
access-list 111 permit tcp any any eq 52323 log
access-list 111 deny ip any any log
!
end
Hier kannst du das nochmal genau sehen mit der "falschen" ACL wenn man das logging mitlaufen lässt und den Zugriff versucht:
Jan 27 16:32:09.195: %SEC-6-IPACCESSLOGP: list 111 denied tcp 10.10.10.1(1288) -> 10.10.10.254(52323), 2 packets cc
Absenderport TCP 1288 und Zielport ist TCP 52323. Letzteren testweise um zu sehen ob Port Translation zwingend erforderlich ist wenn der Router selber auf diese Ports hört.
Auch hier lautet die Antwort NEIN. Das geht wunderbar mit den Standardports.
Mit der richtigen ACL dann die Bestätigung:
Jan 27 16:35:34.611: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 10.10.10.1(1289) -> 10.10.10.254(52323), 1 packet
Erlaubt da TCP 52323 !
Jan 27 16:36:19.743: %SEC-6-IPACCESSLOGP: list 111 denied tcp 10.10.10.1(1290) -> 10.10.10.254(23), 1 packet
Verboten da TCP 23 nicht erlaubt.
Hier siehst du einen Output der statischne Translation für den remote Port Forwarding Zugriff auf den Webserver an .1.166
cisco#sh ip nat trans
Pro Inside global Inside local Outside local Outside global
tcp 10.10.10.254:52323 192.168.7.166:23 --- ---
tcp 10.10.10.254:80 192.168.1.166:80 10.10.10.1:1272 10.10.10.1:1272
tcp 10.10.10.254:80 192.168.1.166:80 10.10.10.1:1273 10.10.10.1:1273
tcp 10.10.10.254:80 192.168.1.166:80 10.10.10.1:1274 10.10.10.1:1274
tcp 10.10.10.254:80 192.168.1.166:80 10.10.10.1:1275 10.10.10.1:1275
tcp 10.10.10.254:80 192.168.1.166:80 10.10.10.1:1276 10.10.10.1:1276
tcp 10.10.10.254:80 192.168.1.166:80 --- ---
Desgleichen der Beweis für das funktionierende PPTP VPN Dialin:
#debug ppp authentication
PPP authentication debugging is on
cisco#
Jan 27 16:24:28.207: ppp2 PPP: Using vpn set call direction
Jan 27 16:24:28.207: ppp2 PPP: Treating connection as a callin
Jan 27 16:24:28.207: ppp2 PPP: Session handle[3F000006] Session id[2]
Jan 27 16:24:28.223: ppp2 PPP: Authorization required
Jan 27 16:24:28.235: ppp2 MS-CHAP-V2: O CHALLENGE id 1 len 33 from "cisco"
Jan 27 16:24:28.243: ppp2 MS-CHAP-V2: I RESPONSE id 1 len 57 from "vpn"
Jan 27 16:24:28.243: ppp2 PPP: Sent MSCHAP_V2 LOGIN Request
Jan 27 16:24:28.283: ppp2 PPP: Received LOGIN Response PASS
Jan 27 16:24:28.291: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up
Jan 27 16:24:28.295: Vi3 PPP: Sent LCP AUTHOR Request
Jan 27 16:24:28.295: Vi3 PPP: Sent IPCP AUTHOR Request
Jan 27 16:24:28.295: Vi3 LCP: Received AAA AUTHOR Response PASS
Jan 27 16:24:28.299: Vi3 IPCP: Received AAA AUTHOR Response PASS
Jan 27 16:24:28.299: Vi3 MS-CHAP-V2: O SUCCESS id 1 len 46 msg is "S=0C0363C3D5E1CE9E1A9D5D5BD66C5EDADCFDDCE8"
Jan 27 16:24:28.303: Vi3 PPP: Sent CCP AUTHOR Request
Jan 27 16:24:28.307: Vi3 CCP: Received AAA AUTHOR Response PASS
Jan 27 16:24:29.291: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up
Fazit: Alles ist gut !! Änder die ACL 111 in die korrigierte Form und dann kommt alles zum Fliegen wie es soll !
Sorry nochmal für die Irreführung aber das passiert in der Hektik mal
Zitat von @aqui:
Hallo Johannes !
Zuerst ein Wort der Entschulgigung. Riesen Denkfehler bei der ACL... war aber wohl der Stress....
Die ACL "access-list 111 permit tcp any eq 443 any" war total falsch !!
Ich war da geistig etwas abwesend...sorry. Richtig (und getestet) lautet die 111er ACL also
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq domain any
access-list 111 permit gre any any
access-list 111 permit tcp any any eq 1723
access-list 111 permit tcp any any eq 22
access-list 111 permit tcp any any eq 443
access-list 111 permit tcp any any eq 5904
access-list 111 permit tcp any any eq 2212
access-list 111 permit tcp any any eq 3389
access-list 111 permit tcp any any eq 8080
access-list 111 deny ip any any
Hallo Johannes !
Zuerst ein Wort der Entschulgigung. Riesen Denkfehler bei der ACL...
war aber wohl der Stress....Die ACL "access-list 111 permit tcp any eq 443 any" war total falsch !!
Ich war da geistig etwas abwesend...sorry. Richtig (und getestet) lautet die 111er ACL also
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq domain any
access-list 111 permit gre any any
access-list 111 permit tcp any any eq 1723
access-list 111 permit tcp any any eq 22
access-list 111 permit tcp any any eq 443
access-list 111 permit tcp any any eq 5904
access-list 111 permit tcp any any eq 2212
access-list 111 permit tcp any any eq 3389
access-list 111 permit tcp any any eq 8080
access-list 111 deny ip any any
Hallo aqui
Vielen Dank nochmals für die Mühen und auch nochmal hier: kein Problem wegen dem Fehler - ich bin Dir unendlich dankbar ob der Mühen und des Aufwandes die Du dir wegen meiner Unkenntnis gemacht hast.
Jedenfalls kann ich berichten: Es geht! Nachdem ich die ACL111 geändert habe, konnte ich wieder von außen auf mein Netzwerk zugreifen. Habe jetzt erstmal nur RDP testen können, aber das sah gut aus und ich gehe davon aus, daß die anderen Protokolle analog funktionieren werden.
ABER
Es gibt auch wieder ein kleines Problem!
Die Regel
ip access-list extended keingast
deny ip 192.168.82.0 0.0.0.255 192.168.92.0 0.0.0.255
permit ip 192.168.82.0 0.0.0.255 any
remark CCP_ACL Category=1
Aus Zeitmangel habe ich jetzt kein debug gemacht - vielleicht hast Du spontan eine Idee was an der Regel korrigiert werden muß?
Viele Grüße & riesen Dank!
Johannes
Mmmmhhh so jetzt keinen Fehler machen 
Nein, Spaß beiseite....
Wir haben auf dem Gast VLAN ja folgendes:
interface Vlan2
description GastWLan
ip address 192.168.82.1 255.255.255.0
ip access-group keingast in
Das heisst incoming "in" (rein ins VLAN 2 Interface) gilt die Accessliste mit dem Namen keingast.
Die filtert alles raus was eine Absender IP 192.168.82.x hat (also vom Gastnetz kommt) und eine Ziel IP von 192.168.92.x (also ins lokale LAN will) und schmeisst diesen Traffic weg.
Sie erlaubt den ganzen Rest also was eine Absender IP 192.168.82.x hat in den Rest der Welt, also Internet !! Fazit: Außer ins .92er Netz dürfen die Gäste überall hin !!
Du siehst.... logisch ist diese ACL also vollkommen korrekt und MUSS auch so funktionieren. Sie blockt lediglich den Versuch wenn Gäste auf das lokale LAN zugreifen wollen ! Allerdings....
Verhindert sie logischerweise auch das du aus dem lokalen LAN ins Gästenetz kommst !
Du kannst also ebenso diesen Zugriff dahin aus dem lokalen LAN nicht machen, da zwar Pakete aus dem lokalen LAN den Zielrechner im Gastnetz erreichen, dessen Antwortpakete aber wiederum dann in der ACL keingast. scheitern, wie sie auch sollen.
Dieser Weg ist also auch versperrt. Soll das erlaubt sein musst du die ACL etwas verändern ?!
Der Rest stimmt auch:
Die Gästenutzer sind mit der ACL 101 die ja beide Netze .82.0 und .92.0 erlaubt:
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
access-list 101 permit ip 192.168.82.0 0.0.0.255 any
auch freigeschaltet (permit) fürs NAT (Adress Translation) auf dem Dialer0 Interface ins Internet
ip nat inside source list 101 interface Dialer0 overload
Also auch hier alles gut.
Und können auch den PPPoE Dialin Prozess zum Provider triggern:
dialer-list 1 protocol ip list 101
Allso alles richtig und gut auch hier
Ändert sich das Verhalten denn wenn du die ACL keingast vom VLAN-2 Interface entfernst ??
Alternativ kannst du sie mal mit
deny ip 192.168.82.0 0.0.0.255 192.168.92.0 0.0.0.255 log
permit ip 192.168.82.0 0.0.0.255 any log
konfigurieren, dann wird dir jeder Hit der ACL mit einem Log Eintrag angezeigt. Hier sieht man dann sofort wo es kneift und kann korrigieren. Später sollte der "log" Parameter dann aber immer rausgenommen werden im Produktivbetrieb !
Generell muss das also eigentlich so klappen und kann kein Fehler der ACL an sich sein.
Zur Sicherheit check ich das im Labor nochmal
Zum Thema IP Adresszuordnung per DHCP:
Deine DHCP Zuordnung und Konfig oben ist syntaktisch vollkommen korrekt. Es sollten sowohl GastLAN als auch LokalLAN User problemlos IP Adressen bekommen ?!
Check das mal mit ipconfig
Was in deiner o.a. Konfig allerdings vollkommen fehlt ist das globale Kommando:
ip dns server
Ohne das ist der Cisco KEIN Proxy DNS und da du den Cisco selber in den DHCP Settings an erster Stelle als DNS angegeben hast kann es hier zu Problemen kommen das DNS Namen nicht oder nur sehr verzögert aufgelöst werden, was für Clients dann immer nach "Internet geht nicht !!" aussieht obwohl es nicht stimmt denn nur DNS geht dann nicht oder nicht richtig.
Der Router zeigt dir mit show ip hosts an ob er DNS Proxy ist und mit ping 8.8.8.8 kannst du immer eine nackte IP Adresse im Internet pingen um DNS Problemen erstmal aus dem Weg zu gehen und zu sehen ob der Internet Zugang generell funktioniert.
Auch direkt von der Cisco Konsole klappt das. Wenn du z.B. einmal "ping <Eingabetaste>" eingibst kannst du den Ping auf dem Router customizen. Wenn du "extended commands" bejahst kannst du testweise eine interne Absender IP angeben und somit auch checken das NAT für beide Netze sauber rennt !
Das solltest du also nochmal genau checken !
Nein, Spaß beiseite....Wir haben auf dem Gast VLAN ja folgendes:
interface Vlan2
description GastWLan
ip address 192.168.82.1 255.255.255.0
ip access-group keingast in
Das heisst incoming "in" (rein ins VLAN 2 Interface) gilt die Accessliste mit dem Namen keingast.
Die filtert alles raus was eine Absender IP 192.168.82.x hat (also vom Gastnetz kommt) und eine Ziel IP von 192.168.92.x (also ins lokale LAN will) und schmeisst diesen Traffic weg.
Sie erlaubt den ganzen Rest also was eine Absender IP 192.168.82.x hat in den Rest der Welt, also Internet !! Fazit: Außer ins .92er Netz dürfen die Gäste überall hin !!
Du siehst.... logisch ist diese ACL also vollkommen korrekt und MUSS auch so funktionieren. Sie blockt lediglich den Versuch wenn Gäste auf das lokale LAN zugreifen wollen ! Allerdings....
Verhindert sie logischerweise auch das du aus dem lokalen LAN ins Gästenetz kommst !
Du kannst also ebenso diesen Zugriff dahin aus dem lokalen LAN nicht machen, da zwar Pakete aus dem lokalen LAN den Zielrechner im Gastnetz erreichen, dessen Antwortpakete aber wiederum dann in der ACL keingast. scheitern, wie sie auch sollen.
Dieser Weg ist also auch versperrt. Soll das erlaubt sein musst du die ACL etwas verändern ?!
Der Rest stimmt auch:
Die Gästenutzer sind mit der ACL 101 die ja beide Netze .82.0 und .92.0 erlaubt:
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
access-list 101 permit ip 192.168.82.0 0.0.0.255 any
auch freigeschaltet (permit) fürs NAT (Adress Translation) auf dem Dialer0 Interface ins Internet
ip nat inside source list 101 interface Dialer0 overload
Also auch hier alles gut.
Und können auch den PPPoE Dialin Prozess zum Provider triggern:
dialer-list 1 protocol ip list 101
Allso alles richtig und gut auch hier
Ändert sich das Verhalten denn wenn du die ACL keingast vom VLAN-2 Interface entfernst ??
Alternativ kannst du sie mal mit
deny ip 192.168.82.0 0.0.0.255 192.168.92.0 0.0.0.255 log
permit ip 192.168.82.0 0.0.0.255 any log
konfigurieren, dann wird dir jeder Hit der ACL mit einem Log Eintrag angezeigt. Hier sieht man dann sofort wo es kneift und kann korrigieren. Später sollte der "log" Parameter dann aber immer rausgenommen werden im Produktivbetrieb !
Generell muss das also eigentlich so klappen und kann kein Fehler der ACL an sich sein.
Zur Sicherheit check ich das im Labor nochmal
Zum Thema IP Adresszuordnung per DHCP:
Deine DHCP Zuordnung und Konfig oben ist syntaktisch vollkommen korrekt. Es sollten sowohl GastLAN als auch LokalLAN User problemlos IP Adressen bekommen ?!
Check das mal mit ipconfig
Was in deiner o.a. Konfig allerdings vollkommen fehlt ist das globale Kommando:
ip dns server
Ohne das ist der Cisco KEIN Proxy DNS und da du den Cisco selber in den DHCP Settings an erster Stelle als DNS angegeben hast kann es hier zu Problemen kommen das DNS Namen nicht oder nur sehr verzögert aufgelöst werden, was für Clients dann immer nach "Internet geht nicht !!" aussieht obwohl es nicht stimmt denn nur DNS geht dann nicht oder nicht richtig.
Der Router zeigt dir mit show ip hosts an ob er DNS Proxy ist und mit ping 8.8.8.8 kannst du immer eine nackte IP Adresse im Internet pingen um DNS Problemen erstmal aus dem Weg zu gehen und zu sehen ob der Internet Zugang generell funktioniert.
Auch direkt von der Cisco Konsole klappt das. Wenn du z.B. einmal "ping <Eingabetaste>" eingibst kannst du den Ping auf dem Router customizen. Wenn du "extended commands" bejahst kannst du testweise eine interne Absender IP angeben und somit auch checken das NAT für beide Netze sauber rennt !
Das solltest du also nochmal genau checken !
Zitat von @aqui:
Generell muss das also eigentlich so klappen und kann kein Fehler der ACL an sich sein.
Zur Sicherheit check ich das im Labor nochmal
Generell muss das also eigentlich so klappen und kann kein Fehler der ACL an sich sein.
Zur Sicherheit check ich das im Labor nochmal
Hallo aqui
danke für Deine Antwort.
Für mich sieht das ja auch logisch aus, doch funktioniert es so nicht. Erst nachdem ich die ACL keingast vom VLAN2 entfernt hatte, bekamen die Rechner dort IPs vom Router zugeordnet und kamen ins Internet.
Wie schon beschrieben habe ich es auch mit manueller IP-Konfiguration eines Clients im 82er Netz versucht - das klappte auch nicht.
Die Konfig "ip dns server" werde ich noch ergänzen...
Johannes
Hallo aqui
Leider noch ein gravierendes Problem.
Der DynDns-Updater funktioniert nicht mehr. Ich benutze dazu ein Script auf dem Server, welches aus dem Aufruf der Seite myip.dnsdynamic.org die aktuelle IP extrahiert und damit mehrere dnsdynamic-Account aktualisiert. Aber auf dem Server ist der Output jeglicher "WieIstMeineIP"-Dienste leer . Da wird wohl irgendwas irgendwo von der Firewall blockiert. Dummerweise habe ich mich jetzt auch noch ausgesperrt (oder neue IP vom Provider).
ich habe auch anhand Deiner Anleitung nen DynDns-Update im Cisco konfiguriert, doch der scheint auch nicht zu laufen .
Määhh !
Johannes
Leider noch ein gravierendes Problem.
Der DynDns-Updater funktioniert nicht mehr. Ich benutze dazu ein Script auf dem Server, welches aus dem Aufruf der Seite myip.dnsdynamic.org die aktuelle IP extrahiert und damit mehrere dnsdynamic-Account aktualisiert. Aber auf dem Server ist der Output jeglicher "WieIstMeineIP"-Dienste leer
. Da wird wohl irgendwas irgendwo von der Firewall blockiert. Dummerweise habe ich mich jetzt auch noch ausgesperrt (oder neue IP vom Provider).ich habe auch anhand Deiner Anleitung nen DynDns-Update im Cisco konfiguriert, doch der scheint auch nicht zu laufen
.Määhh
!Johannes
Das im Tutorial angegebene Script gilt soweit ich mich erinnere NUR für DynDNS oder no-ip als DynDNS Provider.
DynDNS.org kannst du mittlerweile vergessen, da dort dieser Dienst nicht mehr kostenlos ist und es eigentlich nur noch Sinn macht mit no-ip.com zu arbeiten als Dienst...oder eben zu bezahlen !!
Wie es mit no-ip zu machen ist steht hier:
http://www.noip.com/support/knowledgebase/using-your-cisco-router-with- ...
Es ist klar das der DynDNS Updater hängenbleibt wenn du die ACL 111 nicht auch für inbound TCP 80 öffnest. Fast alle dieser Provider nutzen HTTP also Port TCP 80 für diese Requests !!
Siehe auch das Cisco Script: //"http://<username>:<pw>:@members.dyndns.org...."// !
Da dieser wieder mit der Absender IP des Routers rausgeht ist logischerweise wieder die ACL 111 gefragt da die sonst alles blockt was nicht durch CBAC aus dem lokalen LAN kommt. Siehe auch die Erklärung von oben (...die scheinbar nicht bei dir hängen geblieben ist !!!)
Aaaalso wenn es HTTP ist änder die ACL 111 entsprechend wie es auch für DNS gemacht ist:
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq domain any
access-list 111 permit tcp any eq www any
Dann klappts auch wieder mit dem DynDNS.
Bitte mal nachdenken oder den log Debugger einschalten, dann erklärt der Cisco dir es auch selbst
Checke gerade die ACL Thematik nochmal...
DynDNS.org kannst du mittlerweile vergessen, da dort dieser Dienst nicht mehr kostenlos ist und es eigentlich nur noch Sinn macht mit no-ip.com zu arbeiten als Dienst...oder eben zu bezahlen !!
Wie es mit no-ip zu machen ist steht hier:
http://www.noip.com/support/knowledgebase/using-your-cisco-router-with- ...
Es ist klar das der DynDNS Updater hängenbleibt wenn du die ACL 111 nicht auch für inbound TCP 80 öffnest. Fast alle dieser Provider nutzen HTTP also Port TCP 80 für diese Requests !!
Siehe auch das Cisco Script: //"http://<username>:<pw>:@members.dyndns.org...."// !
Da dieser wieder mit der Absender IP des Routers rausgeht ist logischerweise wieder die ACL 111 gefragt da die sonst alles blockt was nicht durch CBAC aus dem lokalen LAN kommt. Siehe auch die Erklärung von oben (...die scheinbar nicht bei dir hängen geblieben ist !!!)
Aaaalso wenn es HTTP ist änder die ACL 111 entsprechend wie es auch für DNS gemacht ist:
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq domain any
access-list 111 permit tcp any eq www any
Dann klappts auch wieder mit dem DynDNS.
Bitte mal nachdenken oder den log Debugger einschalten, dann erklärt der Cisco dir es auch selbst
Checke gerade die ACL Thematik nochmal...
HI aqui
Nachdem ich diesen Code (Posting 26.01.2014 um 15:45) wieder entfernt hatte, funktionierte auch das DynDns-Zeugs (und der ganze Internetverkehr auf dem Server) wieder. Dieser ACL ist wohl nicht so richtig...
Johannes
Nachdem ich diesen Code (Posting 26.01.2014 um 15:45) wieder entfernt hatte, funktionierte auch das DynDns-Zeugs (und der ganze Internetverkehr auf dem Server) wieder. Dieser ACL ist wohl nicht so richtig...
access-list 101 deny ip host 192.168.92.10 any
access-list 101 deny ip host 192.168.92.12 any
access-list 101 deny ip host 192.168.92.13 any
access-list 101 deny ip host 192.168.92.14 any
Johannes
Ja, jedenfalls was die Hosts .10, .12, .13 und .14 anbetrifft. Diese ACL Einträge verbieten das Overload NAT für diese Hosts und auch das triggern der Dialer Liste für den PPPoE Provider Login !
Alles andere sollte nicht beeinflussen.
Eigentlich sind sie auch total überflüssig und werden durch die obigen Einträge:
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
access-list 101 permit ip 192.168.82.0 0.0.0.255 any
obsolet für die ACL 101 ! Mehr muss in diese ACL auch nicht rein wie es ja auch im Tutorial ersichtlich ist.
Darüber hinaus waren sie in deinem letzten Posting der aktuellen Konfig auch NICHT mehr enthalten !! Siehe oben....
Achte bitte darauf das du alte oder geänderte Konfig Details hier auch immer mitteilst, denn sonst suchen wir uns alle einen Wolf wenn wir von falschen aktuellen Konfigurationen des Routers ausgehen !!
Alles andere sollte nicht beeinflussen.
Eigentlich sind sie auch total überflüssig und werden durch die obigen Einträge:
access-list 101 permit ip 192.168.92.0 0.0.0.255 any
access-list 101 permit ip 192.168.82.0 0.0.0.255 any
obsolet für die ACL 101 ! Mehr muss in diese ACL auch nicht rein wie es ja auch im Tutorial ersichtlich ist.
Darüber hinaus waren sie in deinem letzten Posting der aktuellen Konfig auch NICHT mehr enthalten !! Siehe oben....
Achte bitte darauf das du alte oder geänderte Konfig Details hier auch immer mitteilst, denn sonst suchen wir uns alle einen Wolf wenn wir von falschen aktuellen Konfigurationen des Routers ausgehen !!
ACL Check...
So, hier ist nochmal die Laborkonfig:
cisco#show run
!
clock timezone CET 1
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
ip dhcp excluded-address 192.168.87.1 192.168.87.250
!
ip dhcp pool eth2
import all
network 192.168.87.0 255.255.255.0
default-router 192.168.87.1
domain-name test.intern
!
ip inspect name myfw udp
ip inspect name myfw tcp
!
vpdn enable
!
vpdn-group 1
accept-dialin
protocol pptp
virtual-template 1
!
username vpn password test123
!
interface Ethernet0
description Lokales LAN
ip address 192.168.1.201 255.255.255.0
ip nat inside
!
interface Ethernet1
description Internet Simulation
ip address 10.10.10.254 255.255.255.0
ip access-group 111 in
ip nat outside
ip inspect myfw out
!
interface Ethernet2
description Gast LAN
ip address 192.168.87.1 255.255.255.0
ip nat inside
ip access-group keingast in
!
interface Virtual-Template1
description PPTP Einwahl Interface fuer VPN Zugang
ip unnumbered Ethernet0
peer default ip address pool pptp_dialin
no keepalive
ppp encrypt mppe 128 required
ppp authentication ms-chap-v2
!
ip local pool pptp_dialin 192.168.1.207 192.168.1.210
!
ip nat inside source list 101 interface Ethernet1 overload
ip nat inside source static tcp 192.168.1.200 23 interface Ethernet1 52323
ip nat inside source static tcp 192.168.1.200 80 interface Ethernet1 80
!
ip access-list extended keingast
deny ip 192.168.87.0 0.0.0.255 192.168.1.0 0.0.0.255
permit ip 192.168.87.0 0.0.0.255 any
access-list 101 permit ip 192.168.87.0 0.0.0.255 any
access-list 101 permit ip 192.168.1.0 0.0.0.255 any
access-list 111 permit gre any any
access-list 111 permit tcp any any eq 1723
access-list 111 permit tcp any any eq www
access-list 111 permit tcp any any eq 52323
access-list 111 deny ip any any
!
cisco#
Extensive Tests zeigen das die ACL am Gast LAN Port, hier in der Labor Konfig eth2 sauber und problemlos funktioniert und in keinster Weise die Internet Verbindung (hier simuliert mit dem 10.10.10.0 /24 Netz) beider LANs (lokal und Gast) beeinflusst !!
Ein "show ip access-list extended keingast" zeigt auch die entsprechenden Match Hits.
Keine Ahnung was du da gemacht hast aber die "keingast" ACL ist syntaktisch richtig und wasserdicht Labor getestet. Du hast dort irgendwo noch einen Konfig Fehler verbockt...vermutlich ?!
Also nochmal genau prüfen !
So, hier ist nochmal die Laborkonfig:
cisco#show run
!
clock timezone CET 1
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
ip dhcp excluded-address 192.168.87.1 192.168.87.250
!
ip dhcp pool eth2
import all
network 192.168.87.0 255.255.255.0
default-router 192.168.87.1
domain-name test.intern
!
ip inspect name myfw udp
ip inspect name myfw tcp
!
vpdn enable
!
vpdn-group 1
accept-dialin
protocol pptp
virtual-template 1
!
username vpn password test123
!
interface Ethernet0
description Lokales LAN
ip address 192.168.1.201 255.255.255.0
ip nat inside
!
interface Ethernet1
description Internet Simulation
ip address 10.10.10.254 255.255.255.0
ip access-group 111 in
ip nat outside
ip inspect myfw out
!
interface Ethernet2
description Gast LAN
ip address 192.168.87.1 255.255.255.0
ip nat inside
ip access-group keingast in
!
interface Virtual-Template1
description PPTP Einwahl Interface fuer VPN Zugang
ip unnumbered Ethernet0
peer default ip address pool pptp_dialin
no keepalive
ppp encrypt mppe 128 required
ppp authentication ms-chap-v2
!
ip local pool pptp_dialin 192.168.1.207 192.168.1.210
!
ip nat inside source list 101 interface Ethernet1 overload
ip nat inside source static tcp 192.168.1.200 23 interface Ethernet1 52323
ip nat inside source static tcp 192.168.1.200 80 interface Ethernet1 80
!
ip access-list extended keingast
deny ip 192.168.87.0 0.0.0.255 192.168.1.0 0.0.0.255
permit ip 192.168.87.0 0.0.0.255 any
access-list 101 permit ip 192.168.87.0 0.0.0.255 any
access-list 101 permit ip 192.168.1.0 0.0.0.255 any
access-list 111 permit gre any any
access-list 111 permit tcp any any eq 1723
access-list 111 permit tcp any any eq www
access-list 111 permit tcp any any eq 52323
access-list 111 deny ip any any
!
cisco#
Extensive Tests zeigen das die ACL am Gast LAN Port, hier in der Labor Konfig eth2 sauber und problemlos funktioniert und in keinster Weise die Internet Verbindung (hier simuliert mit dem 10.10.10.0 /24 Netz) beider LANs (lokal und Gast) beeinflusst !!
Ein "show ip access-list extended keingast" zeigt auch die entsprechenden Match Hits.
Keine Ahnung was du da gemacht hast aber die "keingast" ACL ist syntaktisch richtig und wasserdicht Labor getestet. Du hast dort irgendwo noch einen Konfig Fehler verbockt...vermutlich ?!
Also nochmal genau prüfen !
