OSPF funktioniert nur bedingt auf OpenVPN Interface [solved]

[Ketanest]

Hallo zusammen,

ich bräuchte da mal eure Hilfe. Ich habe folgenden Aufbau:

2x OPNSense mit je einem WAN und einem LAN Port. Die WAN Ports hängen an einem DSLer (dyn. IP).
Die beiden Firewalls sind mit OpenVPN (UDP, tun, PSK) miteinander verbunden. An einer der Firewalls hängen noch 2 weitere OpenVPN Tunnel (ebenfalls UDP, tun, PSK) zu zwei Servern (feste IP) in Rechenzentren.
Nennen wir die Firewalls mal FW1 und FW2 und die Server SRV1 und SRV2. Die Server SRV1 und SRV2 hängen mit je einem OpenVPN Tunnel an FW1.

Auf beiden Firewalls ist OSPFv2 aktiv (frr 7.5), die OpenVPN-Interfaces sind jeweils als Interfaces hinterlegt, das LAN-Interface jeweils als passives Interface. Auf FW1 gibts noch zwei Remote-VPN-Tunnel, die ebenfalls als Passive Interfaces im OSPF drinhängen. Route Redistribution ist deaktiviert, da ich nur meine gewählten Interfaces im OSPF haben will. Sonst habe ich das Problem, wenn ich Connected Routes einschalte, dass ich auf den beiden Servern SRV1 und SRV2 sowie auf den Firewalls die jeweils öffentlichen IP-Adressen der anderen Geräte gepusht kriege, was ich zum einen nicht möchte und teilweise (logischerweise) zum Abbruch der VPN-Verbindung führt. Auf SRV1 und SRV2 ist frr (8.1) installiert und das OpenVPN Interface als OSPF Interface ausgewählt.

Ich habe jetzt folgenden Effekt: Die Routen der physischen Interfaces (LAN) werden weitergegeben, die Routen der virutellen Interfaces (OpenVPN) leider nicht. Z.B. hat SRV1 keine Kenntnis vom OpenVPN-Netz zwischen FW1 und SRV2. Ich habe nebenbei auch OSPFv3 am Laufen, da funktioniert das Ganze einwandfrei, auch die Routen der OpenVPN-Interfaces werden weitergegeben.

Woran könnte das Ganze liegen? Ich hab mir schon die Finger wund gegooglet aber nix gefunden. "Downgrade" auch frr 7.5 auf Seiten der Server hat auch nix gebracht. Reboot tut gut half auch hier nicht. Da die physischen Interface Routen ja verteilt werden, kann man ja ein Routing oder Firewall-Problem ausschließen oder?

Hat jemand da ne Idee? Auf die Config von FW2 hab ich leider grad keinen Zugriff.

Danke euch auf jeden Fall schonmal!

Gruß
Ketanest

Das wäre die OSPF-Config auf FW1

Code Select Expand

Building configuration...

Current configuration:
!
frr version 7.4
frr defaults traditional
hostname OLC-FW1.wikl.local
log syslog notifications
!
interface openvpn
ip ospf area 0.0.0.0
!
interface ovpnc3
ip ospf area 0.0.0.0
!
interface ovpnc4
ip ospf area 0.0.0.0
!
interface ovpns1
ip ospf area 0.0.0.0
ipv6 ospf6 passive
!
interface ovpns5
ip ospf area 0.0.0.0
ipv6 ospf6 passive
!
interface ovpns6
ip ospf area 0.0.0.0
!
interface pppoe0
ip ospf network broadcast
!
interface re0
ip ospf area 0.0.0.0
ipv6 ospf6 passive
!
interface re1_vlan41
ip ospf area 0.0.0.0
!
router ospf
ospf router-id 192.168.10.1
passive-interface openvpn
passive-interface ovpns1
passive-interface ovpns5
passive-interface re0
passive-interface re1_vlan41
!
router ospf6
ospf6 router-id 192.168.10.1
interface ovpnc3 area 0.0.0.0
interface ovpnc4 area 0.0.0.0
interface re0 area 0.0.0.0
interface ovpns1 area 0.0.0.0
interface ovpns5 area 0.0.0.0
interface ovpns6 area 0.0.0.0
!
line vty
!
end


OSPF-Config SRV1:

Code Select Expand

Building configuration...

Current configuration:
!
frr version 8.1
frr defaults traditional
hostname hetzner-vs1
log syslog informational
service integrated-vtysh-config
!
interface tun0
ip ospf area 0.0.0.0
ipv6 ospf6 area 0.0.0.0
exit
!
router ospf
ospf router-id 192.168.100.1
exit
!
router ospf6
ospf6 router-id 192.168.100.1
exit
!
end


und SRV2:

Code Select Expand

Building configuration...

Current configuration:
!
frr version 8.1
frr defaults traditional
hostname netcup-vs1
log syslog informational
service integrated-vtysh-config
!
interface tun0
ip ospf area 0.0.0.0
ipv6 ospf6 area 0.0.0.0
exit
!
router ospf
ospf router-id 192.168.104.1
exit
!
router ospf6
ospf6 router-id 192.168.104.1
exit
!
end


[mimugmail]

Bei OPN sollte die area in die router config, nichts ins Interface

[Ketanest]

Die OPN generiert ja anhand der Einstellungen im Webinterface die Config.
FRR ist hier noch Version 7.5 da kommt's tatsächlich noch in die Interface Config Section.

Gruß
Ketanest

[mimugmail]

Ne, du kannst im Network Tab und im Interface Tab die Area setzen, im Interface leer lassen und dafür nur in Network, dann geht's

[Ketanest]

Hab ich probiert, gleiches Problem: LAN wird verteilt, die VPNs wieder nicht. EDIT: 10.er Router wird wieder verteilt, die andren nicht.
Hiernochmal die Config (10.0 ist LAN, 100.0 und 104.0 sind die OpenVPN-Netze)

Code Select Expand

Building configuration...

Current configuration:
!
frr version 7.4
frr defaults traditional
hostname OLC-FW1.wikl.local
log syslog notifications
!
interface ovpns1
ipv6 ospf6 passive
!
interface ovpns5
ipv6 ospf6 passive
!
interface re0
ipv6 ospf6 passive
!
router ospf
ospf router-id 192.168.10.1
passive-interface ovpns1
passive-interface ovpns5
passive-interface re0
passive-interface re1_vlan41
network 192.168.10.0/24 area 0.0.0.0
network 192.168.100.0/24 area 0.0.0.0
network 192.168.104.0/24 area 0.0.0.0
!
router ospf6
ospf6 router-id 192.168.10.1
interface ovpnc3 area 0.0.0.0
interface ovpnc4 area 0.0.0.0
interface re0 area 0.0.0.0
interface ovpns1 area 0.0.0.0
interface ovpns5 area 0.0.0.0
interface ovpns6 area 0.0.0.0
!
line vty
!
end



[mimugmail]

Was genau verstehst du unter "verteilt"? Bei tun in OpenVPN müssen die Netze auch definiert sein. Sonst siehst du sie nur in OSPf aber ohne Routing

[Ketanest]

Mit "verteilt" meine ich die Weitergabe von Routen.

Bei tun in OpenVPN müssen die Netze auch definiert sein. Sonst siehst du sie nur in OSPf aber ohne Routing

Wie genau darf ich das verstehen? Wenn ich die Netze alle in tun definiere, ist der Sinn von OSPF verfehlt. Wenn ich auf den Firewalls unter Route Redistribution die "Connected Routes" aktiviere, kriegen SRV1 und SRV2 ja sämtliche Netze, die den Firewalls bekannt sind (also auch die jeweils "anderen" OpenVPN Netze, EDIT: "andere" heißt die, an denen sie nicht selbst beteiligt sind) aber mit dem Nebeneffekt, dass auch je die öffentliche IP der Firewalls in die Routingtabelle von SRV1 und 2 eingetragen wird, was wie beschrieben logischerweise zum Abbruch der VPN Verbindung führt. Mit OSPFv3 funktioniert es genau wie ich das möchte (und wie ich es kenne): Interface auswählen, Area eintragen und alle am Interface befindlichen Netze werden per OSPF bekannt gemacht auf allen anderen OSPF-Interfaces (außer den passiven). Die passiven Interfaces sind ja nur dazu da, die dranhängenden Netze bekannt zu machen aber aufm Interface selbst kein OSPF zu sprechen oder versteh ich das falsch?

Aktuell ist es so: das jeweilige OpenVPN Netz (192.168.100.0/24 und 192.168.104.0/24) ist auf den beteiligten Geräten (FW1 und SRV1 bzw. SRV2) bekannt. Mein LAN hat die 192.168.10.0/24. Wenn ich nun (EDIT: auf FW1) die Schnittstellen OpenVPN-SRV1, OpenVPN-SRV2 sowie LAN als Schnittstellen im OSPF hinterlege (mit Area 0.0.0.0) hab ich auf SRV1 im OSPF und in der lokalen Routingtabelle sein eigenes OpenVPN-Netz, das LAN hinter FW1 und das LAN hinter FW2. Auf SRV2 hab ich ebenfalls FW1 LAN, FW2 LAN und das SRV2 OpenVPN-Netz. Auf SRV1 sehe ich aber weder im OSPF noch in der lokalen Routingtabelle das OpenVPN-Netz von SRV2 und SRV2 nicht das SRV1 VPN Netz. Das OpenVPN-Netz zwischen FW1 und FW2 taucht auch nur auf den beiden Geräten auf. Wenn ich die Area wie du sagtest auf den Interfaces rauslasse und stattdessen (als Beispiel für FW1) die von FW1 betroffenen Netze (LAN, Openvpn zu SRV1, OpenVPN zu SRV2 und die Remote OpenVPN-Netze) als Netze anlege, habe ich dasselbe Ergebnis: LAN wird bekannt gemacht, die OpenVPN Netze nicht.

Gruß
Ketanest

[marcquark]

Die Probleme kenne ich. Ohne tief in der Materie zu sein vermute ich hier irgendwelche Quirks mit den OpenVPN Interfaces, die von FRR anscheinend anders behandelt werden. Könnte zusätzlich noch einen Unterschied geben zwischen Linux und Free-/HardenedBSD, das habe ich nicht überprüft.

Mein "Standard" Setup für OSPF, welches bisher bei OPNsense, EdgeRoutern und der anderen Sense immer funktioniert hat, ist folgendes:

• Im General Tab alle Interfaces, an denen kein benachbarter Router hängt, als Passive auswählen
• Route Redistribution Connected Routes aktivieren
• Unter Interfaces alle Interfaces, deren Netze verteilt werden sollen, eintragen und dort auch die Area setzen

Den Networks Tab lasse ich einfach leer.  Die Routen zu den OpenVPN Interfaces tauchen dann als external im OSPF auf. Zwar auch noch nicht ganz so geil, da die mMn nicht external sein sollten, aber das Routing klappt, das ist ja die Hauptsache.
Für das Problem mit den WAN Adressen baue ich immer eine Route Map als doppelten Boden, die nur lokale Adressen erlaubt und den Rest denied. Diese setze ich als Redistribution Map. Auf diese Art ist man auch gegen ein "Whoopsie" abgesichert.

Es scheint auch zu funktionieren, nur die Passive Interfaces auszuwählen, aber im Interfaces Tab nicht noch mal alles durchzuklicken (bis auf die OpenVPN Interfaces die müssen da glaube ich hin). Dann stehen allerdings alle Routen als "external" in der Tabelle. Das sieht für mich irgendwie immer unschön aus, deswegen klicke ich die noch mal zusätzlich in den Interfaces Tab. Aber ich hab' zu wenig Plan von OSPF und auch keine Lust mich mehr damit auseinanderzusetzen (s.u.). Praktische Auswirkungen sind wahrscheinlich eher gering.


Last but not least: Persönlich nehme ich immer mehr Abstand von OSPF. Es ist irgendwie immer fummelig ans Laufen zu bekommen. Und es bleibt immer das schleichende Gefühl, dass man mal irgendwo vergisst etwas explizit als "passive" zu deklarieren und/oder per Firewall zu vernageln. Dadurch besteht immer die Angst, dass irgendwann mal jemand das Routing sehr einfach kaputt machen kann, egal ob als Angriff oder durch einen Flüchtigkeitsfehler.

BGP ist was das angeht charmanter, und mittlerweile mein präferiertes Protokoll auch für internes Routing. Die Beziehung zwischen den Peers wird explizit hergestellt. Die Nutzung von TCP ist etwas firewallfreundlicher. Jede Site kriegt eine AS Nummer zwischen 64512 und 65535, Route redistribution an und los geht's. Das versehentliche einkippen von WAN Adressen ins interne Routing lässt sich hier ebenfalls über einfache Prefix Lists vermeiden. Sogar etwas besser, da man sowohl Inbound als auch Outbound filtern kann. D.h. auch wenn am anderen Ende mal jemand unqualifiziert an der Router Config friemelt, fällt nicht direkt das ganze Netzwerk um.

Die Standardtimer im BGP sind allerdings sehr träge. Mittlerweile kann man die pro Peer explizit setzen (das hat mimugmail eingebaut) oder einfach in den "General" Settings die Defaults auf "Datacenter" stellen. Das findest du unter Advanced Settings, habe ich vor einiger Zeit mal eingebaut. Klappt tadellos. Dazu noch die "Graceful Restart" Option nutzen. Sonst sorgt ein Daemon Restart dafür, dass Routen kurz verschwinden und dann wieder auftauchen - das kann je nach Anwendungsfall egal sein, aber du willst es in täglichen Operations eigentlich vermeiden, insbesondere wenn deine verteilte Anwendung es noch nicht so mit der Fehlertoleranz hat und ständig Fehler wirft, wenn mal ein paar TCP Verbindungen abreißen ;-)

[fabian]

Last but not least: Persönlich nehme ich immer mehr Abstand von OSPF. Es ist irgendwie immer fummelig ans Laufen zu bekommen. Und es bleibt immer das schleichende Gefühl, dass man mal irgendwo vergisst etwas explizit als "passive" zu deklarieren und/oder per Firewall zu vernageln. Dadurch besteht immer die Angst, dass irgendwann mal jemand das Routing sehr einfach kaputt machen kann, egal ob als Angriff oder durch einen Flüchtigkeitsfehler.

Das müsste ich ausschließen können. Das Plugin legt automatisch die Firewall-Regeln an, da das im UI gar nicht möglich ist, derartige Regeln für Multicast vor der Bogon / RFC-1918 Blockliste anzulegen.

[marcquark]

Last but not least: Persönlich nehme ich immer mehr Abstand von OSPF. Es ist irgendwie immer fummelig ans Laufen zu bekommen. Und es bleibt immer das schleichende Gefühl, dass man mal irgendwo vergisst etwas explizit als "passive" zu deklarieren und/oder per Firewall zu vernageln. Dadurch besteht immer die Angst, dass irgendwann mal jemand das Routing sehr einfach kaputt machen kann, egal ob als Angriff oder durch einen Flüchtigkeitsfehler.

Das müsste ich ausschließen können. Das Plugin legt automatisch die Firewall-Regeln an, da das im UI gar nicht möglich ist, derartige Regeln für Multicast vor der Bogon / RFC-1918 Blockliste anzulegen.

Interessant... Wann wurde das etwa eingebaut? Ich hab' hier gerade nur virtuelle Instanzen mit "echten" Interfaces als Verbindung untereinander. Da funktioniert es tatsächlich ohne explizite Regel.

Als ich vor ca. einem Jahr eine etwas größere OPNsense Migration gemacht habe, mussten wir die Regeln anlegen. Da waren OpenVPN und routed IPSec S2S Verbindungen zwischen OPNsense Clustern mit CARP im Spiel. Also möglicherweise mehrere Stellen, an denen es Bugs geben könnte. Aber wir mussten explizit die allow Regeln anlegen, sonst ging es nicht (block private/block bogon war aus).

Grobe Vermutung, es hängt mit routed IPSec zusammen. Da war es ja bisher immer so, dass man keine Regeln auf die Interfaces setzen konnte, sondern die immer auf enc0 mussten, vielleicht fehlt das im Plugin?
Geht das eigentlich mit FreeBSD 13? Wäre extrem angenehm. Mit >2 Tunneln hat man sonst nämlich schnell eine sehr große und unübersichtliche Tabelle auf dem "IPSec" Interface.

[Ketanest]

Mein "Standard" Setup für OSPF, welches bisher bei OPNsense, EdgeRoutern und der anderen Sense immer funktioniert hat, ist folgendes:

• Im General Tab alle Interfaces, an denen kein benachbarter Router hängt, als Passive auswählen
• Route Redistribution Connected Routes aktivieren
• Unter Interfaces alle Interfaces, deren Netze verteilt werden sollen, eintragen und dort auch die Area setzen

Den Networks Tab lasse ich einfach leer.  Die Routen zu den OpenVPN Interfaces tauchen dann als external im OSPF auf. Zwar auch noch nicht ganz so geil, da die mMn nicht external sein sollten, aber das Routing klappt, das ist ja die Hauptsache.
Für das Problem mit den WAN Adressen baue ich immer eine Route Map als doppelten Boden, die nur lokale Adressen erlaubt und den Rest denied. Diese setze ich als Redistribution Map. Auf diese Art ist man auch gegen ein "Whoopsie" abgesichert.

Das hatte ich auch schon versucht, allerdings hab ich das nicht hinbekommen, wie genau hast du die gebaut? Wenn ich hier nämlich ein 192.168.0.0/16 baue, gehts nicht und wenn ich da wieder jedes Netz einzeln eintragen muss kann mir mir OSPF sparen. Oder ich habs einfach falsch gemacht, kann auch sein  ;D

EDIT: Das mit den Route Maps sowie Prefix Lists sowie deren Zusammenhang hab ich leider nicht wirklich verstanden. Dazu hab ich leider zu wenig Erfahrung mit OSPF. Hat da eine vielleicht nen verständlichen Erklärungsansatz für?

Gruß
Ketanest

[fabian]

Interessant... Wann wurde das etwa eingebaut? Ich hab' hier gerade nur virtuelle Instanzen mit "echten" Interfaces als Verbindung untereinander. Da funktioniert es tatsächlich ohne explizite Regel.

https://github.com/opnsense/plugins/blob/master/net/frr/src/etc/inc/plugins.inc.d/frr.inc
November 2018.

Grobe Vermutung, es hängt mit routed IPSec zusammen. Da war es ja bisher immer so, dass man keine Regeln auf die Interfaces setzen konnte, sondern die immer auf enc0 mussten, vielleicht fehlt das im Plugin?
Geht das eigentlich mit FreeBSD 13? Wäre extrem angenehm. Mit >2 Tunneln hat man sonst nämlich schnell eine sehr große und unübersichtliche Tabelle auf dem "IPSec" Interface.

Keine Ahnung

[Ketanest]

Sooo, jetzt läufts endlich  :)

Hab mich damit abgefunden, dass es scheinbar Probleme mit frr und OpenVPN gibt. Ich teste das mal noch auf Linux (Debian) aus, vielleicht liegt es ja wirklich an BSD.

Config ist jedenfalls folgende:

Code Select Expand


Building configuration...

Current configuration:
!
frr version 7.4
frr defaults traditional
hostname OLC-FW1.wikl.local
log syslog notifications
!
interface ovpnc3
ip ospf area 0.0.0.0
!
interface ovpnc4
ip ospf area 0.0.0.0
!
interface ovpns1
ip ospf area 0.0.0.0
ipv6 ospf6 passive
!
interface ovpns5
ip ospf area 0.0.0.0
ipv6 ospf6 passive
!
interface ovpns6
ip ospf area 0.0.0.0
!
interface re0
ip ospf area 0.0.0.0
ipv6 ospf6 passive
!
interface re1_vlan41
ip ospf area 0.0.0.0
!
router ospf
ospf router-id 192.168.10.1
redistribute connected route-map RouteMap
passive-interface ovpns1
passive-interface ovpns5
passive-interface re0
passive-interface re1_vlan41
!
router ospf6
ospf6 router-id 192.168.10.1
interface ovpnc3 area 0.0.0.0
interface ovpnc4 area 0.0.0.0
interface re0 area 0.0.0.0
interface ovpns1 area 0.0.0.0
interface ovpns5 area 0.0.0.0
interface ovpns6 area 0.0.0.0
!
ip prefix-list PermitOnlyInt seq 20 permit 192.168.0.0/16 ge 24
ip prefix-list PermitOnlyInt seq 30 deny 0.0.0.0/0 le 32
!
route-map RouteMap permit 10
match ip address prefix-list PermitOnlyInt
!
line vty
!
end


Gruß
Ketanest

[Ketanest]

EDIT: Das mit den Route Maps sowie Prefix Lists sowie deren Zusammenhang hab ich leider nicht wirklich verstanden. Dazu hab ich leider zu wenig Erfahrung mit OSPF. Hat da eine vielleicht nen verständlichen Erklärungsansatz für?

Gruß
Ketanest

Das ist damit natürlich obsolet geworden, so halbwegs hab ichs jetzt verstanden.

[Patrick M. Hausen]

Den Networks Tab lasse ich einfach leer.  Die Routen zu den OpenVPN Interfaces tauchen dann als external im OSPF auf. Zwar auch noch nicht ganz so geil, da die mMn nicht external sein sollten, aber das Routing klappt, das ist ja die Hauptsache.

Das ist gar nicht so problematisch wie Du befürchtest, sondern das Standard-Setup einiger mittlerer ISPs, jedenfalls derer, die noch OSPF als IGP benutzen.

Wenn Du alle Routen innerhalb deines AS oder einer Area hälst, dann führt jedes Togglen eines Links dazu, dass alle Router innerhalb der Area wieder Dijkstra laufen lassen müssen, um aus der LSDB die Topologie zu berechnen.

Wenn man nur die Links zwischen Routern einer Area als Teil des AS/der Area betrachtet und einfach alles andere per (in Cisco Syntax)

Code Select Expand

redistribute connected subnets
redistribute static subnets
als external LSA in die LSDB kippt, dann bekommt man schnelle Konvergenz und Redistribution ohne Topologieänderungen und Aufwand auf jedem einzelnen Router.

Machen wir seit 20 Jahren so ...

Für das Problem mit den WAN Adressen baue ich immer eine Route Map als doppelten Boden, die nur lokale Adressen erlaubt und den Rest denied. Diese setze ich als Redistribution Map. Auf diese Art ist man auch gegen ein "Whoopsie" abgesichert.

Dito. Das ist eigentlich eine hervorragende Idee und m.E. Best Practice. Die pauschale Aussage "bei OSPF kann man nicht filtern" gilt nämlich nur, wenn man alle Links als Teil des AS betrachtet. Was wir - s.o. - nicht tun. In dem Fall müssen nämliche alle Router die komplette LSDB haben, damit sie das "SPF" (Dijkstra) laufen lassen können und zu konsistenten Ergebnissen kommen.
An einem ASBR dagegen kann man per Redistribute-Map ganz prima filtern, wie du richtig beschrieben hast.

Das sieht für mich irgendwie immer unschön aus, deswegen klicke ich die noch mal zusätzlich in den Interfaces Tab. Aber ich hab' zu wenig Plan von OSPF und auch keine Lust mich mehr damit auseinanderzusetzen (s.u.). Praktische Auswirkungen sind wahrscheinlich eher gering.

Du machst alles richtig und external LSAs sind ganz prima :)

Gruß
Patrick