Schlagwort: ASA

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.

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 ASA Factory reset & firmware per tftp

Eigentlich sollte die ASA bei auslieferung in einem default Zustand sein, so das man z.B. über einen dhcp auf dem Management port eine Verbindung bekommen sollte – sagt Cisco.
So scheint es zumindest bei den hier geliferten 5550 nicht zu sein. aber man kann diesen Zustand durcht ein
conf t
configure factory-default

schnell wieder herstellen.

mittels
ciscoasa(config)# copy tftp flash
Address or name of remote host [192.168.1.12]? 192.168.1.2
Source filename [asdm-621.bin]?
Destination filename [asdm-621.bin]?
Accessing tftp://192.168.1.2/asdm-621.bin...!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

bzw.
ciscoasa(config)# copy tftp flash
Address or name of remote host [192.168.1.2]?
Source filename [asdm-621.bin]? asa821-k8.bin
Destination filename [asa821-k8.bin]?
Accessing tftp://192.168.1.2/asa821-k8.bin...!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
kann man über einen geeigneten tftp schnell eine aktuelle Firmware einspielen

Cisco ASA – ASDM error: Unconnected sockets not implemented

Ähnlich wie dem anderen asdm Problem gibt es noch andere schöne Fehler die beim starten des ASDMs auftreten können. In diesem Fall ASA 8.04 und ASDM 6.13, welche auf einer ASA 5550 vorinstalliert waren.
Laut diesem Blog kann man das Problem mit einer älteren Java Version oder einem neueren ASDM lösen ich habe letzteres gemacht und per tftp die asa-821 und asdm-621 installiert.

Und: die ASA 5550 kopiert deutlich fixer als z.B. eine 5520 😉 16 MB in gefühlten 5 Sekunden.. endlich mal Geschwindigkeit bei Cisco.

Cisco ASA Active Standby Failover konfigurieren

Situation ist folgende: man hat zwei Cisco ASA und möchte diese für die Ausfallsicherheit als Active/Standby Cluster konfigurieren.
Hier ist eine Möglichkeit,

Der einfachste Weg ist sicher der das ASDM zu nutzen, dafür sind ein paar vorarbeiten sinnvoll:
Per Konsole anhängen, im „initial configuration mode“ auf beiden ASAs je eine IP Adresse für das interne Interface definieren z.B. 192.168.1.1 und 192.168.1.2, asdm mittels
http server enable
http 192.168.1.0 255.255.255.0 inside
freischalten.
Dann verbindet man die ASAs mittels failover links z.B. jeweils gig 0/3
Im ASDM unter Wizards nutzt man den High Availability Wizard.
als Peer IP die Adresse der zweiten ASA: 192.168.1.2 ggf. muss man im Java Dialog dem SSL Zertifikat der zweiten ASA trauen, und schon sollte es gehen.
Als failover Link Interface nimmt man das verbundene (gig 0/3) und denkt sich dafür zwei Ips aus (192.168.133.1 und als Standby IP 192.168.133.2).

Gut zu Wissen: Die jeweils aktive Unit hat immer die Active IP, die andere immer die Standby IP.

Man gibt ein gutes (langes) Password an, das den failover link verschlüsselt und schon sollte man fertig sein.

Um die anderen Interfaces auch mit in den Failover zu nehmen muß man ihnen eine Standby IP geben:
Configuration ->Device Management -> High Availability -> Failover -> Interfaces und da bei den angelegten Interfaces die Standby Ip angeben.
Logischerweise müßen diese natürlich dann im gleichen Netz liegen – physikalisch müßen die Interface von beiden ASAs im gleichen VLAN/im Selben Netz liegen.
Das geht mit VLAN Interface ebenso.

ASDM startet nicht mit java.lang.NullPointerException Vista Business 32 Bit

Die neuen ASDMs in dem Fall 6.1.5(51) wollte unter Vista Business 32Bit bei mir nicht starten:

Java.lang.NullPointerException
at sun.swing.table.DefaultTableCellHeaderRenderer.getColumnSortOrder(Unknown Source)
at com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer.getTableCellRendererComponent(Unknown Source)
at wb.getTableCellRendererComponent(DashoA10*..:757)
at v1.b(DashoA10*..:216)
at vz.createDefaultColumnsFromModel(DashoA10*..:1497)
at javax.swing.JTable.tableChanged(Unknown Source)
at vz.tableChanged(DashoA10*..:1389)
at javax.swing.table.AbstractTableModel.fireTableChanged(Unknown Source)
at javax.swing.table.AbstractTableModel.fireTableStructureChanged(Unknown Source)
at v6.a(DashoA10*..:197)
at vz.setModel(DashoA10*..:237)
at vy.aj(DashoA10*..:93)
at vy.a(DashoA10*..:88)
at vy.(DashoA10*..:65)
at va.(DashoA10*..:33)
at u8.(DashoA10*..:35)
at ng.a(DashoA10*..:79)
at nc.b(DashoA10*..:360)
at nc.(DashoA10*..:272)
at com.cisco.pdm.PDMApplet.start(DashoA10*..:159)
at com.cisco.nm.dice.loader.r.run(DashoA19*..:410)
java.lang.NullPointerException
at sun.swing.table.DefaultTableCellHeaderRenderer.getColumnSortOrder(Unknown Source)
at com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer.getTableCellRendererComponent(Unknown Source)
at v1.b(DashoA10*..:216)
at vz.createDefaultColumnsFromModel(DashoA10*..:1497)
at javax.swing.JTable.tableChanged(Unknown Source)
at vz.tableChanged(DashoA10*..:1389)
at javax.swing.JTable.setModel(Unknown Source)
at vz.setModel(DashoA10*..:235)
at y2.d(DashoA10*..:138)
at y2.(DashoA10*..:72)
at va.(DashoA10*..:37)
at u8.(DashoA10*..:35)
at ng.a(DashoA10*..:79)
at nc.b(DashoA10*..:360)
at nc.(DashoA10*..:272)
at com.cisco.pdm.PDMApplet.start(DashoA10*..:159)
at com.cisco.nm.dice.loader.r.run(DashoA19*..:410)
Exception in Starting Main window
Exception in thread "SGZ Loader: launchSgzApplet" java.lang.NullPointerException
at com.cisco.pdm.PDMApplet.start(DashoA10*..:165)
at com.cisco.nm.dice.loader.r.run(DashoA19*..:410)

Die Lösung war Java 1.6.11 zu entfernen und 1.6.7 zu nutzen, damit funktioniert alles wie es soll.. Solche Software liebt man!

Update: Es geht auch mit der Version 1.6.13 nicht, dafür funktioniert es zumindest mit letzterer Java Version problemlos unter Windows XP Pro. Soviel also zu „Java ist plattformunabhängig“

Update2:
Bei Cisco wird der Bug als CSCsw43498 geführt und ist in der Interimsversion asdm 6.1.57 behoben.
als Workaround beschreibt Cisco:
1. Right-click on the Cisco ASDM Launcher shortcut.
2. Select "Property"
3. Click on "Compatibility"
4. Click on the box "Disable Visual Theme"
5. Restart ASDM