pfSense liefert Quagga mit, eine Cisco ASA bietet OSPF als Routingprotokoll an, warum nicht zwischen beiden Systemen mit OSPF routen? Die Implementierung gestaltet sich als recht interessant.
Folgende Topologie wird verwendet:
Auf der pfSense wird unter System -> Package Manager -> Available Packages das Paket Quagga_OSPF installiert. FRR wäre ebenfalls eine Möglichkeit, habe ich mir bisher jedoch noch nicht unter pfSense angeschaut.
Unter Services -> Quagga OSPFd werden die Grundeinstellungen vorgenommen. Wichtig: viele Dinge können nicht direkt über das Webinterface eingestellt werden, hier macht sich die CLI wesentlich besser.
Passwort, Logging, Router-ID und eine Area müssen eingestellt werden.
Weitere Konfigurationen können hier angeklickt werden. Bei einem CARP-Cluster sollte dringend eine IP / Schnittstelle zur Überwachung eingestellt werden, andernfalls kann es zu Routing-Loops kommen. SAVE anklicken.
Jetzt wird ein Interface ausgewählt, hier das WAN-Interface. Auch hier wird eine Area eingetragen.
Weitere Einstellungen, wie Passwörter, Timer etc. können hier ebenfalls vorgenommen werden. Auf SAVE klicken.
Damit ist die Grundeinstellung abgeschlossen. Alles weitere kann auf der CLI eingerichtet werden. Per SSH auf die pfSense gehen.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
ssh admin@192.168.0.10
grumpy@host:~$ ssh admin@192.168.0.10
Password for admin@pf1.decon230.org:
VirtualBox Virtual Machine - Netgate Device ID: 5fdd84f59e0b78379b1a
*** Welcome to pfSense 2.4.2-RELEASE-p1 (amd64) on pf1 ***
WAN (wan) -> em0 -> v4: 172.22.94.11/24
LAN (lan) -> em1 -> v4: 192.168.0.10/24
0) Logout (SSH only) 9) pfTop
1) Assign Interfaces 10) Filter Logs
2) Set interface(s) IP address 11) Restart webConfigurator
3) Reset webConfigurator password 12) PHP shell + pfSense tools
4) Reset to factory defaults 13) Update from console
5) Reboot system 14) Disable Secure Shell (sshd)
6) Halt system 15) Restore recent configuration
7) Ping host 16) Restart PHP-FPM
8) Shell
Enter an option: 8
[2.4.2-RELEASE][admin@pf1.decon230.org]/root:
Damit die CLI vernünftig arbeitet führe ich vorher ein
[2.4.2-RELEASE][admin@pf1.decon230.org]/root: setenv VTYSH_PAGER cat
aus.
[2.4.2-RELEASE][admin@pf1.decon230.org]/root: vtysh
Hello, this is Quagga (version 1.2.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
pf1.decon230.org#
Im Konfigurationsmodus (conf t) werden die Interfaces mit Beschreibungen versehen:
1
2
3
4
5
6
7
interface em0
description ->ASA
ip ospf authentication message-digest
ip ospf message-digest-key 42 md5 password
interface em1
description ->LAN
Die direkt angebundenen Netze aus dem Bereich 192.168.0.0/16 sollen redistributiert werden. Da auch noch andere Netze direkt angeschlossen sind, muss eine Route-Map erstellt werden.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
pf1.decon230.org# sh ip route connected
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, P - PIM, A - Babel, N - NHRP,
> - selected route, * - FIB route
C>* 127.0.0.0/8 is directly connected, lo0
C>* 172.22.94.0/24 is directly connected, em0
C>* 192.168.0.0/24 is directly connected, em1
ip prefix-list connected-into-ospf seq 10 permit 192.168.0.0/16 le 32
ip prefix-list connected-into-ospf seq 20 deny any
route-map connected-into-ospf permit 10
match ip address prefix-list connected-into-ospf
Remote Logins auf den Quaggaprozess müssen unterbunden werden.
1
2
line vty
no login
Jetzt kann der OSPF-Prozess eingerichtet werden.
1
2
3
4
5
6
7
router ospf
ospf router-id 172.22.94.11
log-adjacency-changes detail
redistribute connected route-map connected-into-ospf
passive-interface default
no passive-interface em0
network 172.22.94.0/24 area 0.0.0.0
Damit ist Quagga konfiguriert. Ein wr mem damit die Konfiguration gespeichert wird. Achtung: diese wird durch ein Reboot wieder zurückgesetzt! Es wird wieder in das Webinterface gewechselt, Services -> Quagga OSPFd -> Raw Config.
Die Konfiguration wird orange hinterlegt sein. Der Knopf “Copy OSPFd Running to Saved” muss angeklickt werden. Das Gleiche muss mit der Zebrakonfiguration wiederholt werden, diese befindet sich weiter unten. Auch hier “Copy Zebra Running to Saved” anklicken. Erst wenn alle Konfigurationen grün hinterlegt sind, wird die Konfigration beim Neustart in der Form geladen, wie sie auf der CLI eingegeben wurde.
Damit läuft der OSPF Prozess, es wird jedoch keine Nachbarschaft zur ASA zustande kommen. Die ASA wird im Status INIT/DRother verbleiben. Ursache sind fehlende ACLs auf der pfSense, welche OSPF Multicastpakete blocken.
Unter Firewall -> Rules -> Floating müssen zwei Einträge erstellt werden:
Es muss das Protokoll OSPF auf seine entsprechenden Multicast-Adressen 224.0.0.4 und 224.0.0.5 erlaubt werden. Anschließend wird eine Nachbarschaft zur ASA aufgebaut.
1
2
Neighbor ID Pri State Dead Time Address Interface
172.22.94.11 1 FULL/DR 0:00:39 172.22.94.11 lab-test
Die Konfiguration der ASA sieht folgendermaßen aus:
1
2
3
4
5
6
7
8
9
router ospf 65523
router-id 172.22.94.1
network 172.22.94.0 255.255.255.0 area 0
log-adj-changes detail
interface Vlan94
ip address 172.22.94.1 255.255.255.0
ospf message-digest-key 42 md5 *****
ospf authentication message-digest
Ein sho route zeigt die OSPF E2-Route:
1
2
O E2 192.168.0.0 255.255.255.0
[110/20] via 172.22.94.11, 0:00:37, lab-test
Bei diesem Beispiel sollte daran gedacht werden, dass externe OSPF-Routen nicht zusammengefasst werden können. Dies könnte u. U. die Routingtabelle füllen und zu Ressourcenproblemen führen.