Kategorie: Job

Fortigate: Zwei WAN Schnittstellen/ISPs nutzen, einen default Weg haben

Möchte man bei einer Fortigate zweit WAN Zugänge oder ISPs anschliessen, z.B. für Backup oder Lastverteilung kommt man zu dem Punkt: Wie geht das?

Szenario:
Einen Provider am WAN1 (schnelle Leitung)
zweiten Provider am WAN2 (langsamere Verbindung)

Wie kann man vorgehen?
Legt man zwei default Routen mit unterschiedlichen Metriken an ist nur die mit der besseren Metrik in der Routingtabelle, d.h. es wird nur die bessere Route genutzt, Verbindungen über die andere Leitung schlägt fehl (RPF wird das wohl verhindern).

Also trägt man zwei default Routen mit gleicher Metrik an!
Jetzt macht die Fortigate standardmäßig ECMP – also Lastverteilung. Beide Leitungen werden genutzt. Leider schert sich die Fortigate nicht um die Bandbreite (ggf kann man da in den aktuellen Versionen mit weightend ECMP was drehen), wird also recht fix die langsamere Leitung überlasten.

Die Lösung: Prioritäten für Routen. Das ist ähnlich wie Metriken, verhindert aber nicht das die Route aus der Routing Tabelle verschwindet. Sind zwei Routen zum Ziel da wird die mit der niedrigeren Priorität gewählt. bei gleicher Prio greift wieder ECMP.
Dadurch die Route in der Routing Tabelle vorhanden ist kann man Sessions über beide WAN Verbindungen aufbauen und mittel Policy Routing auch einzelnen Traffic über eine WAN Strecke forcieren (z.B. http Traffic über die langsamere Verbindung).

Die Prioritäten kann man nur über die CLI einrichten.
Beispiel:

config router static
show

Die entsprechenden Einträge anpassen
edit 1
" set device ""wan1"""
set gateway 192.168.1.100
set priority 1
next
edit 2
" set device ""wan2"""
set priority 5
set gateway 172.16.31.254
next
In diesem Fall würde der Traffic defaultmäßig über WAN1 gehen (niedrigere Priorität), aber eingehender Verkehr über WAN2 wird erlaubt. Fällt WAN1 weg geht der Verkehr über WAN2.

Natürlich muss man sich noch um passende VIPs/ACLs an den entsprechenden Interfaces kümmern und auch DNS im Hinterkopf behalten.

Die ASA von Cisco hat sowas meines Wissens nicht, es gibt immer nur eine aktive Defaultroute Loadbalancing kann sie nicht. Ein Failover kann man ggf mit SLAs.

Nicht cisco GBICs/SFPs

Cisco will das man nur seine eigenen GBICs benutzt. Bei manchen 3rd Party SFPs gibt es dann Fehler:
%PHY-4-UNSUPPORTED_TRANSCEIVER: Unsupported transceiver found in Gi1/0/1
%GBIC_SECURITY_CRYPT-4-VN_DATA_CRC_ERROR: GBIC in port gi 1/0/1 has bad crc

Mittels der undokumentierten Befehle
service unsupported-transciever
no errdisable detect cause gbic-invalid

kann man sein Glück trotzdem versuchen.
Das klappt nicht auf allen Plattformen und leider nicht mit allen GBICs/SFPs, aber ein Versuch sollte es wert sein.

Cisco Router, NAT und IPSec

Vielleicht kommt man mal in die Verlegenheit, das man nicht alle Daten in einen VPN Tunnel schicken will, sondern einen „local internet breakout“ haben möchte. Man schmeisst also nur ein paar Daten in den Tunnel, der Rest wird dynamisch genattet..

Nehmen wir an das lokale Netz ist 10.10.1.0/24 die Netze in der zentrale, die per Tunnel erreicht werden sind 10.10.20.0/24 und 172.16.2.0/24.

Man erstellt eine ACL die den zu verschlüsselnden Traffic denied

access-list 110 deny ip 10.10.1.0 0.0.0.255 10.10.20.0 0.0.0.255
access-list 110 deny ip 10.10.1.0 0.0.0.255 172.16.2.0 0.0.0.255
access-list 110 permit ip 10.10.1.0 0.0.0.255 any

Jetzt bindet man das an eine Routemap

route-map permit_NAT
permit 10 match ip address 110

Danach benutzt man die Routemap im nat statement:

ip nat inside source route-map permit_NAT interface fast0/0 overload

Und definioert nachher noch nat Inside und outside


int fa0/0
description outside
nat outside
[..]
int fa0/1
description inside
nat inside
[..]

Natürlich muss man auch sicherstellen, dass die routen für den verschlüsselten Traffic auch auf die Tunnel Interface zeigen (dynamisches Routing Protokolle wie eigrp/ospf oder statische Routen)

mit show ip nat translation kann man schauen ob es translations fürs Internet gibt, ansonsten mal testen ob der zugriff in die Zentrale noch geht.

Cisco ASA für den Zugriff mit SSH konfigurieren

Will man die ASA per SSH administrieren, muss man erst an ein paar Schräubchen drehen:
Wie auf einem Router ein Key Pärchen erzeugen und braucht natürlich auch einen User und SSH muß diesen User zum authentifizieren benutzen:

Auf der CLI einen user anlegen:

username admin password MeinTollesPasswort privilege 15

Authentifizierung local erfolgen lassen

aaa authentication http console LOCAL
aaa authentication ssh console LOCAL

RSA Schlüssel erzeugen:

crypto key generate rsa

management Access freigeben Hier erlaube ssh von 192.168.1.0/24 auf dem Management Interface:

ssh 192.168.1.0 255.255.255.0 management

ASDM
Im ASDM ist es etwas versteckter und umständlicher.

User anlegen:
Configuration > Device Management > Users/AAA > User Accounts --> Add
Usernamen, Passwort, Privilege Level eintragen

Authentifizierung mit lokalen Usern für ASDM und SSH
Configuration > Device Management > Users/AAA > AAA Access > Authentication
–> HTTP/ASDM und SSH ankreuzen

RSA Schlüssel anlegen:
Configuration > Device Management > Certificate Management > Identity Certificates
–> Add –> Add New Identity Certificate und dann neben „Key Pair“ auf New klicken.

ManagementAccess freigeben:
Configuration > Device Management > Management Access > ASDM/HTTPS/Telnet/SSH
Hier mit Add für SSH und HTTPS/ASDM die entsprechenden Einträge machen

Dann sollte es auch mit dem adminsitrieren klappen.

Cisco Die richtige Zeit Einstellung – Uhr und Sommerzeit

Zeitangaben im Logfile sind wichtig, wer will schon anhand der uptime Zurückrechnen, wann es zum Fehler gekommen ist?

Folgendes hilft:

service timestamps debug datetime localtime
service timestamps log datetime localtime
clock timezone MET 1
clock summer-time MEST recurring last Sun Mar 2:00 last Sun Oct 3:00

Die Zeit stellt man dann mit
clock set 15:230:25 14 Dec 2009

Cisco SSH hostname geändert – Putty gibt Fehlermeldung „Incorrect CRC received on Packet“

Bei einem Cisco 7200 sollte ich den hostname und den domain-name ändern.

Danach war kein einloggen per SSH mehr möglich.

Nov 27 12:22:08: %SSH-3-PRIVATEKEY: Unable to retrieve RSA private key for oldhostname.olddomain-name.de
-Process= „SSH Process“, ipl= 0, pid= 105
-Traceback= 61E7EA5C 61E7B180 61E7C9A4 607D752C 607D7510

Hmm da scheint er den Key des ehemaligen Hosts nehmen zu wollen.. seltsam.

crypto key zerorize rsa
hat nichts gebracht nach erzeugen eines neuen Schlüssels kommt der gleiche Fehler.

Lösung ist hier dem ssh key ein Label zu geben und dem ssh daemon zu sagen er möge doch diesen Schlüssel mit dem bestimmten Label nutzen:
crypto key zeroize rsa
crypto key generate rsa general keys label [hostname] modulus 1024
ip ssh rsa keypair-name [hostname]

Schon klappt es auch wieder mit den Nachbarn.