Der (fast) perfekte Home-Office-Router

Gerade habe ich testweise meinen ersten Cisco 866VAE-k9 installiert. Hier beschreibe ich ein paar Eindrücke von diesem Gerät.

Warum der 866VAE-k9
Ich wollte einen IOS-Router mit eingebautem VDSL-Modem. Eine Zeitlang hatte ich eine Fritzbox als DSL-Router und Telefonanlage laufen, aber das ist einfach zu unflexibel. Die Fritzbox bleibt zwar die Telefonanlage bis ich da etwas besseres finde, aber als Router wollte ich ein vollwertiges IOS-Gerät haben, das zumindest anständig VPNs beherrscht und auch Policy-Based Routing kann. Zusätzlich benötigte ich DNS-Views um selektiv DNS-Abfragen an den DNS-Server im Büro zu senden. Weiterhin sollte der Router keinen oder zumindest einen sehr leisen Lüfter haben.
Meine Wahl fiel dann auf den Cisco 866VAE-k9, der ein eingebautes DSL-Modem hat, ohne Lüfter daherkommt und zudem noch recht günstig ist. Meine erste Befürchtung war zwar, dass er am 50 MBit-VDSL überfordert wäre, aber dort wurde ich angenehm überrascht.

Die VDSL-Konfig
Die Konfiguration des VDSLs bei diesem Router weicht deutlich von der ADSL-Konfig ab, wie sie auf älteren Geräten durchgeführt wurde. Hier ein kleiner Auszug aus der Konfig:

controller VDSL 0
 operating mode vdsl2
!
interface Ethernet0
 description VDSL Internet Verbindung - VLAN 7 tagged
 no ip address
 no ip route-cache cef
!
interface Ethernet0.7
 encapsulation dot1Q 7
 pppoe-client dial-pool-number 1
!
interface Dialer0
 description log. WAN-Interface
 dialer pool 1

Für VDSL erwartet die Telekom die Daten getagged mit VLAN 7. Dafür wird das logische Interface Ethernet0 verwendet, das als physikalischer Port nicht vorhanden ist.

Die VPN-Konfig
Die ist nicht weiter erwähnenswert da der Router wie jeder andere IOS-Router konfiguriert wird. Allerdings werden nicht alle VPN-Arten unterstützt. IKEv1 und IKEv2 sind beide supported, Crypto-Maps und VTIs gehen natürlich auch und FlexVPN soll ebenfalls gehen. DMVPN ist anscheinend nicht supported. Mit FlexVPN ist aber ein leistungsfähiger Nachfolger verfügbar. Auch WebVPN ist nicht enthalten, aber das ist bei der angepeilten Zielgruppe wohl auch nicht notwendig.
Ich habe mein VPN wegen der dynamischen IP-Adresse mit einem Virtual Tunnel Interface (VTI) auf der Spoke-Seite und einem dynamic Virtual Tunnel Interface (dVTI) auf der Hub-Seite konfiguriert.

Routing-Möglichkeiten:
Bei dVTIs muss die Aussenstelle mit dynamischem Routing angebunden werden. Da kann es von Nachteil sein, dass der Router kein OSPF und EIGRP unterstützt (der Router benutzt ein Advanced Security Image; diese haben auch bei anderen 800er Routern sehr eingeschränkte Routing-Möglichkeiten). Diese Routing-Protokolle sind unterstützt:

inet-home(config)#router ?
  bgp  Border Gateway Protocol (BGP)
  odr  On Demand stub Routes
  rip  Routing Information Protocol (RIP)

inet-home(config)#router

Eine echte Einschränkung sind die angebotenen Protokolle natürlich auch nicht, vor allem da BGP/ODR und RIP noch besser skalieren als EIGRP oder OSPF wenn eine sehr große Anzahl von Aussenstellen vorhanden sind. Ich habe jetzt unidirectional RIP für die Verbindung ins Büro laufen was auch sehr gut funktioniert.

Geschwindigkeit am Telekom-VDSL:
Da war ich wie schon erwähnt sehr überrascht. Bei ein paar massiven Downloads steigt die CPU-Last des Routers zwar auf gute 50%, aber dabei erreiche ich Download-Raten von guten 5.2 bis 5.3 MB/s. Mit der FritzBox 7390 habe ich nie über 4.9 bis 5.0 MB/s erreicht.

Aber natürlich gibt es ein paar Nachteile:

  1. Das Flash: Wir haben 2014 und das Flash ist so klein, dass man nicht einmal ein zweites Image ablegen kann. Das ist einfach nur peinlich!
  2. inet-home#sh flash:
    57344K bytes system flash allocated
    
    Directory of flash:/
    
        2  -rwx    28385048  Jan 31 2014 13:02:11 +01:00  c860vae-advsecurityk9-mz.152-4.M5.bin
        4  -rwx         780  Apr 19 2014 23:10:08 +02:00  vlan.dat
    
    55351296 bytes total (26959872 bytes free)
  3. CPU-Power
  4. Das muss ich noch etwas weiter untersuchen. Aber das Upgrade des Routers auf das neuere IOS 15.2(4)M6a lief über das LAN mit ca, 20 KB/s. Das war die CPU-Auslastung dabei:

    CPU utilization for five seconds: 99%/1%; one minute: 99%; five minutes: 97%
     PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
     234     1367564       10866     125857 97.20% 97.27% 94.18%   4 SSH Process

    Jetzt muss aber vor dem Update wegen des knappen Flashs das alte IOS gelöscht werden. Wenn dann das Update sehr lange dauert und der Router dabei eine sehr hohe Last hat, dann wäre mir etwas mulmig wenn ich das remote durchführen müsste.

  5. Keine VRFs
  6. Ok, für so ein kleines Gerät sollte man das auch nicht erwarten, aber die Trennung von internem und public Routing wäre schon schön!

Fazit?
Der Router ist recht günstig und kommt daher natürlich mit einigen Nachteilen. Wenn diese bekannt und nicht zu störend sind, dann ist der 866VAE sicher ein guter Kauf. Wenn etwas mehr Budget zur Verfügung steht würde ich aber doch lieber zu einem 886VAer greifen.

Der (fast) perfekte Home-Office-Router

Und wieder eine MD5-Verwendung weniger!

Der Untergang von MD5 ist nicht aufzuhalten. Zwar sehe ich auch heute noch immer wieder neue VPN-Konfigs, die mit MD5 arbeiten, aber nach und nach wird auch im Cisco IOS die Verwendung von MD5 reduziert. Während früher lokale Passwörter mit MD5 gehashed wurden, wird in aktuellen IOS-Versionen dafür SHA256 verwendet, was mit dem Password-Typ “4” gekennzeichnet wird:

R1(config)#username cisco secret 1234QWerYXcv

R1(config)#do sh run | i username
username cisco secret 4 irYgUmM5jSgCvMDO0jEQ3Z65YnGxJ1JbHhX4TrRyGX2
Und wieder eine MD5-Verwendung weniger!

Cisco IOS: Content-Filtering

Das Filtern von URLs ist eine Funktion, die ich normalerweise auf einem dedizierten Proxy implementieren würde. Aber wenn kein Proxy zur Verfügung steht, kann diese Funktion auch lokal auf dem IOS-Router ab Version 12.4(20)T konfiguriert werden. Dabei stehen drei Mechanismen zur Verfügung:

  1. Ein lokal installierter Websense oder Secure Computing Server
  2. Abfrage des “cloud-based” Trend Micro URL-Filtering Dienstes
  3. lokale Black- oder Whitelists

Um zu testen, ob die Trend Micro-Lösung als Alternative in Branch-Offices einsetzbar ist, habe ich auf meinem Cisco 1841 mit IOS 15.1(3)T die Test-Lizenz installiert. Diese kann pro Router einmal aktiviert werden und läuft dann für dreißig Tage. Der Straßenpreis der Lizenz für die 1800er oder 1900-Serie liegt für 1 Jahr bei ca. 200 Euro, was die Sache recht interessant macht.
Die Konfiguration des Content-Filters ist in die Zone-Based-Firewall integriert, was die Implementierung sehr flexibel macht (wobei böse Zungen behaupten “flexibel” wäre nur eine Umschreibung für “unnötig kompliziert”; eine Behauptung, der ich nur schwer widersprechen kann).
In der Cisco-Dokumentation ist die Konfiguration auch recht gut beschrieben, weshalb ich hier nicht näher darauf eingehe. Nach der “Fleiß-Arbeit”, mit der Cisco Common Classification Policy Language (C3PL) die Zonen-basierte Konfiguration anzufertigen, gilt es aus den 70 URL-Kategorien (wie z.B. Auctions, Games, Nudity, Pornography, Shopping, Travel, Weapons) und den 10 Security-Kategorien (wie z.B. ADWARE, HACKING, PHISHING) die richtigen auszuwählen, die geblockt werden sollen.

Was kam weiter beim Test heraus:

  • Wie ich vorher auch schon bei N2H2 — jetzt Secure Computing — festgestellt habe, ist der Filter bei deutschen Seiten bei weitem nicht so gut wie bei englischem Content (z.B. beim Zugriff auf .com-Seiten).
  • Viele Seiten, die eigentlich bei meinen Tests hätten geblockt werden sollen, wurden vom Filter erlaubt. Schade eigentlich. Oftmals zeigte sich auch, das nur Teile zu blockender Seiten nicht angezeigt wurden. Wenn ich die Kategorie “Violence-hate-racism” blocke und die Seite des Ku Klux Klan aufrufe, dann werden zwar alle Bilder und Elemente der Webseite geblockt, der Text der Hauptseite erscheint aber trotzdem. Genauso z.B. beim Blocken von “Real-estate”. Die Seite immonet.de erscheint schon, es werden aber keine sonstigen Elemente dargestellt.
  • “Photo-Searches” blockt nicht photoblog.msnbc.msn.com.
  • “Nudity” blockt kein http://www.coupe.de, keine BILD und auch keine getesteten FKK/Nudisten-Seiten.
  • Von den im Bundestag vertretenen Parteien werden in der Kategorie “Political” nur die Linken geblockt, NPD geht, die DVU hingegen nicht.
  • Die Kategorie “Auctions” filtert recht gut, wenn auch der Zugriff auf http://www.zoll-auktion.de nicht geblockt wird. Das hätte ich allerdings auch nicht erwartet.
  • Die CPU-Belastung steigt durch die Nutzung des Content-Filters natürlich auch. Mit dem getesteten Cisco 1841 an meinem 16000er DSL-Anschluss erreiche ich bei HTTP-Downloads zwar wie auch ohne Content-Filter eine Geschwindigkeit von ca. 1,6 bis 1,7 MByte/s. Die CPU-Last liegt dabei aber durchgängig bei über 95%. Der “normale” Wert bei Downloads beträgt ca. 85%, was natürlich auch grenzwertig ist, aber halt auch nur bei längeren Downloads vorkommt. Dieser Anstieg reicht aber schon, das ich diese Lösung für meine Kunden, die in den Branches meist 1800er Router haben, für nicht geeignet halte. Wenn neuere Standorte mit 1900er Routern bestückt werden sollte man die Sache aber erneut analysieren. Bei den deutlich schnelleren ISR-G2 kann ich mir aber vorstellen, das es schon ganz anders aussieht.

Weitere Informationen zum Thema IOS Content-Filter und Zone-Based-Firewalls:

Cisco IOS: Content-Filtering

Cisco IOS: DNS-Views

Heute lese ich im IPExpert-Blog über DNS-Views und sage mir, “Hey, darüber habe ich doch auch gerade geschrieben”. Nun, geschrieben schon, aber noch nicht veröffentlicht, was ich hiermit nachhole:

Über den im IOS eingebauten DNS-Server habe ich schon vor längerer Zeit berichtet. Seit einiger Zeit (genauer gesagt seit IOS 12.4(9)T) unterstützt das IOS auch sogenannte DNS-Views. Dabei werden die DNS-Anfragen in Abhängigkeit der angefragten Domains an unterschiedliche DNS-Server gesendet. Ich benutze das z.B. für Wartungszugänge zu Kunden. Wenn eine Anfrage an server.firma1.local am DNS-Server ankommt, wird die Anfrage über das Firma1-VPN weitergeleitet, bei allen anderen Anfragen aber an den DNS-Server des Providers.

Die Konfiguration startet mit den DNS Name-Lists. In diesen werden per Regular Expression die Domain-Namen oder FQDNs beschrieben, für die eine abweichende Behandlung gewünscht ist. In meinem Fall ist dies eine Namensauflösung durch einen anderen DNS-Server:

ip dns name-list 1 permit .firma.local

Als nächstes werden die DNS-Views konfiguriert:

ip dns view FIRMA
 logging
 dns forwarder 10.11.12.13
 dns forwarding source-interface Vlan254
ip dns view default
 logging
 domain timeout 2
 dns forwarder 8.8.8.8

In meinem Beispiel gibt es eine dedizierte View FIRMA und eine optionale default-View.
In der View FIRMA setze ich den zuständigen DNS-Server und die Source-Adresse der Anfrage, damit die Anfrage auch wirklich durch den VPN-Tunnel gesendet wird. Die Default-View verwendet den Google DNS-Server. Für beide Views wird das Logging aktiviert.

Die Verwendung der beiden Views muss als nächstes aktiviert werden:

ip dns view-list DNS
 view FIRMA 10
  restrict name-group 1
 view default 1000
!
ip dns server view-group DNS

Die View-List mit dem Namen DNS spezifiziert, welche View für welche Domains verwendet werden soll. Die View FIRMA wird dabei nur für die Domains verwendet, die in der name-list 1 spezifiziert wurden. Die View default wird für den gesamten Rest verwendet. Die “10” und “1000” gibt dabei die Priorität der Einträge in der List an.
Die View-List kann dann entweder Interface-basiert, oder global (wie in diesem Beispiel) angewendet werden.

Durch das Logging kann man kontrollieren ob die Views verwendet werden:

Feb 20 19:41:34.213 CET: %DNS-6-LOG_ACCESS: DNS View default used for client 10.255.253.74/1904, querying A 'time.apple.com'
Feb 20 19:42:41.301 CET: %DNS-6-LOG_ACCESS: DNS View FIRMA used for client 10.255.250.2/62733, querying AAAA 'www.firma.local'
Cisco IOS: DNS-Views

Cisco IOS 12.4(15)T14: Du hast mich so enttäuscht!

Lange Zeit hätte ich auf dieses IOS-Release nichts kommen lassen. “T14” hatte lange Zeit zum reifen und war ausserordentlich stabil. Vor einiger Zeit aber häuften sich bei Kunden die Probleme. Auf verschiedenen Routern (1802, 2811, 2611XM) und verschiedenen Feature-Sets (AdvSecurity und AdvIPServices) kam es zu Verzögerungen beim Zugriff auf das Internet. Das äußerte sich so, das z.B. jeder Seitenzugriff verzögert ablief, es danach aber mit normaler Geschwindigkeit weiterging. Mein erster Gedanke war “ok, dann bringt mal euer DNS in Ordnung”, denn diese Art Fehler sind fast immer in der DNS-Konfiguration zu finden. Diesmal aber war die Namensauflösung korrekt und auch normal schnell. Das Problem zeigte sich dann aber bei der Analyse mit tcpdump/Wireshark:

  • Auf dem PC wurde das initiale TCP-SYN gesendet, das zugehörige SYN-ACK kam ziemlich genau drei Sekunden später. Die nächsten Pakete wurden ohne besondere Verzögerung übertragen.
  • Auf dem Zielserver kam das initiale TCP-SYN erst mit drei Sekunden Verzögerung an und alles lief ohne Verzögerung.

Drei Sekunden, in denen der Router dieses erste Paket einer neuen Verbindung nicht weitergesendet hat! Und so ein Verhalten gehört sich einfach nicht für einen anständigen Router! Der Wechsel auf das IOS 12.4(22)T5 hat dann Abhilfe geschaffen. Aber das war trotzdem einer der ekligsten Fehler, der mir bisher untergekommen ist.

Cisco IOS 12.4(15)T14: Du hast mich so enttäuscht!

Cisco IOS: EIGRP-Authentifizierung mit Key-Rollover

Über die Qualität der Cisco Schulungsunterlagen habe ich mich schon ab und an mal ausgelassen.
Und während ich mich gerade auf eine neue Kursversion eines Security-Kurses vorbereite, fällt mir schon wieder eine Sache auf, die man besser nicht so macht, wie es im Kurs beschrieben ist. Beim Thema Routing-Protokoll-Authentifizierung findet sich dort eine Key-Chain mit den folgenden send- und accept-lifetimes:

key chain MYKEYS
 key 1
   key-string ThisIsKey1
   accept-lifetime 04:00:00 Jan 1 2010 04:00:00 Feb 1 2012
   send-lifetime 04:00:00 Jan 1 2010 04:00:00 Jan 1 2012
 key 2
   key-string ThisIsKey2
   accept-lifetime 04:00:00 Jan 1 2012 04:00:00 Feb 1 2014
   send-lifetime 04:00:00 Jan 1 2012 04:00:00 Jan 1 2014

Die accept-lifetime des zweiten Keys schließt sich hier genau an die sent-lifetime des ersten Keys an.
Was passieren kann, wenn man es genau so konfiguriert, habe ich in GNS3 nachgestellt (GNS3-Datei und Konfiguration):

EIGRP-Authentication zwischen Router1 und
Router2
R0#ping ipv6 R2-Loopback0 repeat 500
Type escape sequence to abort. Sending 500, 100-byte ICMP Echos to 2001:DB8:2222::12, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!...............!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!
R1:
Jan 1 03:59:56.435: IPv6-EIGRP: received packet with MD5 authentication, key id = 1
Jan 1 04:00:01.135: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:03.971: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:03.983: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 100: Neighbor FE80::C202:30FF:FE3F:0 (FastEthernet0/0) is down: Interface Goodbye received 
Jan 1 04:00:08.495: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:13.423: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:17.767: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:22.339: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:26.723: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:31.683: IPv6-EIGRP: received packet with MD5 authentication, key id = 2 
Jan 1 04:00:32.551: IPv6-EIGRP: received packet with MD5 authentication, key id =2
R2:
Jan 1 03:59:28.843: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 03:59:33.271: IPv6-EIGRP: pkt authentication key id = 2, key not defined or not live 
Jan 1 03:59:33.271: EIGRP: FastEthernet0/0: ignored packet from FE80::C201:30FF:FE3F:0, opcode = 5 invalid authentication)
Jan 1 03:59:33.271: EIGRP: Dropping peer, invalid authentication 
Jan 1 03:59:33.275: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 100: Neighbor FE80::C201:30FF:FE3F:0 (FastEthernet0/0) is down: Auth failure 
Jan 1 03:59:37.823: IPv6-EIGRP: pkt authentication key id = 2, key not defined or not live 
Jan 1 03:59:37.823: EIGRP: FastEthernet0/0: ignored packet from FE80::C201:30FF:FE3F:0, opcode = 5 (invalid authentication) ... 
Jan 1 03:59:57.347: IPv6-EIGRP: pkt authentication key id = 2, key not defined or not live 
Jan 1 03:59:57.347: EIGRP: FastEthernet0/0: ignored packet from FE80::C201:30FF:FE3F:0, opcode = 1 (invalid authentication) 
Jan 1 04:00:01.851: IPv6-EIGRP: received packet with MD5 authentication, key id = 2 
Jan 1 04:00:01.851: EIGRP: Received HELLO on FastEthernet0/0 nbr FE80::C201:30FF:FE3F:0 
Jan 1 04:00:01.851: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 
Jan 1 04:00:01.851: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 100: Neighbor FE80::C201:30FF:FE3F:0 (FastEthernet0/0) is up: new adjacency

Was ist da passiert? Für dieses Beispiel habe ich die Uhren beider Router mit einer Differenz von 30 Sekunden konfiguriert. Solche und größere Zeitabweichnungen habe ich auch schon in Netzen mit NTP gesehen. Im Normalbetrieb sollte das zwar nicht auftreten, aber durch Konfigurations-Probleme kann ein NTP-Server halt auch mal nicht erreichbar sein. Und ein Grundsatz guten Netzwerk-Designs heißt halt mit Recht “Always Plan for Problems”.
Für 30 Sekunden (das ist die Zeitspanne am 1.1.2012 von 04:00:00 bis 04:00:30 auf Router1 bzw. von 03:59:30 bis 04:00:00 auf Router2) wird der Router1 den ersten Key nicht mehr verwenden, dieser würde aber von Router2 noch akzeptiert werden. Dafür verwendet Router1 den zweiten Key, dieser wird aber von Router2 noch nicht akzeptiert:

Die sent- und accept-lifetimes (nicht proportional gezeichnet)

Der Verbindungsabbruch von ca. 30 Sekunden ergibt sich daher, das der Router2 bei einer fehlerhaften
Authentifizierung sofort die Nachbarschaftsbeziehung abbricht und erst wieder aufbaut, wenn beide Router den Key 2 benutzen können. Router1 hat in dieser Zeit keine fehlerhaften Authentifizierungen.
Das Problem lässt sich recht einfach vermeiden, indem man die accept-lifetime nicht nur länger laufen lässt als die sent-lifetime, sondern auch vor der sent-lifetime des nächsten Keys beginnen lässt:

Die accept-lifetime beginnt jetzt vor der send-lifetime

Was passiert jetzt in diesen 30 Sekunden:

  • Router1 sendet seine Pakete schon mit Key 2, der auch von Router 2 akzeptiert wird.
  • Router2 sendet seine Pakete noch mit Key 1, der von Router 1 noch akzeptiert wird.

Die (relevante) Konfiguration von Router2 sieht dabei folgendermaßen aus. Wie lang man dabei die accept-lifetime überlappen lässt hängt natürlich von den persönlichen Vorlieben ab. Ich habe für dieses Beispiel einfach fünf Minuten genommen:

hostname R1
!
key chain MYKEYS
 key 1
   key-string ThisIsKey1
   accept-lifetime 04:00:00 Jan 1 2010 04:00:00 Feb 1 2012
   send-lifetime 04:00:00 Jan 1 2010 04:00:00 Jan 1 2012
 key 2
   key-string ThisIsKey2
   accept-lifetime 03:55:00 Jan 1 2012 04:00:00 Feb 1 2014
   send-lifetime 04:00:00 Jan 1 2012 04:00:00 Jan 1 2014
!
interface FastEthernet0/0
 ipv6 address 2001:DB8:2::11/64
 ipv6 eigrp 100
 ipv6 authentication mode eigrp 100 md5
 ipv6 authentication key-chain eigrp 100 MYKEYS
!
ipv6 router eigrp 100
 router-id 1.1.1.1
 no shutdown

Wer sich darüber wundert, das ich dieses Beispiel mit IPv6 aufgebaut habe, dem sei der Beitrag Blog Examples Going IPv6 Next Year von PacketLife.net zu empfehlen. Diese Idee werde ich aufgreifen und ab sofort meine Beispiele auch mit IPv6 implementieren, wo es möglich ist.

Cisco IOS: EIGRP-Authentifizierung mit Key-Rollover