OPNsense 2 Provider: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
← Zum vorherigen Versionsunterschied
Link zur Animation ergänzt
 
(25 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== Ausgangspunkt ==
* Diese Übung beginnt auf einer '''frisch aus dem ausgegebenen OPNsense-Template geklonten Firewall''', ohne Reste aus früheren Übungen (NAT, Regeln, Bridges, VPN).
* Beim Klonen '''neue MAC-Adressen für alle Netzwerkkarten''' erzeugen.
* HA und Multi-WAN werden nicht kombiniert: jede Übung bekommt ihre eigene frische Firewall.
== Plan ==
== Plan ==


Zeile 18: Zeile 23:
Interfaces angelegt werden. Sie müssen nicht fortlaufend zu den Gerätenamen passen – wichtig ist
Interfaces angelegt werden. Sie müssen nicht fortlaufend zu den Gerätenamen passen – wichtig ist
nur, dass sie in Gateways, DNS und Regeln konsistent referenziert werden.''
nur, dass sie in Gateways, DNS und Regeln konsistent referenziert werden.''
* Animation: [https://xinux.org/opnsense-multiwan.html OPNsense Multi-WAN: zwei Provider] ([https://xinux.org/opnsense-multiwan-einfach.html einfach])


== Was müssen wir tun? ==
== Was müssen wir tun? ==
Zeile 31: Zeile 38:
* NAT-Regeln anpassen
* NAT-Regeln anpassen
* Szenarien testen
* Szenarien testen
== Voraussetzungen ==
* Virtuelle Maschine mit 5 Netzwerkschnittstellen (VirtualBox: LAN, WAN1, WAN2, DMZ, Reserve)
* Zeitzone unter ''System: Settings: General'' auf <code>Europe/Berlin</code> setzen (nicht <code>Etc/UTC</code>)
* Systemdomain prüfen: <code>it34.xinux.de</code>


== Konfiguration ==
== Konfiguration ==
Zeile 61: Zeile 62:
| IPv6 Configuration Type || None
| IPv6 Configuration Type || None
|-
|-
| IPv4 address || 192.168.HS.2XX /24
| IPv4 address || 192.168.HS.2XX/24
|-
|-
| IPv4 Upstream Gateway || WAN1GW
| IPv4 Upstream Gateway || hier kommt später '''WAN1GW''' rein
|}
|}


Zeile 78: Zeile 79:
| Enable || aktiv
| Enable || aktiv
|-
|-
| Device || em5
| Device || em4
|-
|-
| Description || WAN2
| Description || WAN2
Zeile 92: Zeile 93:
| IPv4 address || 172.30.34.2XX/24
| IPv4 address || 172.30.34.2XX/24
|-
|-
| IPv4 Upstream Gateway || WAN2GW
| IPv4 Upstream Gateway || hier kommt später '''WAN2GW''' rein
|}
|}


Zeile 108: Zeile 109:
| Address Family || IPv4 || IPv4
| Address Family || IPv4 || IPv4
|-
|-
| IP Address || 192.168.HS.254 || 172.34.30.254
| IP Address || 192.168.HS.254 || 172.30.34.254
|-
|-
| Upstream Gateway || '''aktiv''' || '''aktiv'''
| Upstream Gateway || '''aktiv''' || '''aktiv'''
Zeile 116: Zeile 117:
| Disable Gateway Monitoring || aus || aus
| Disable Gateway Monitoring || aus || aus
|-
|-
| Monitor IP || 8.8.8.8 || 9.9.9.9
| Monitor IP || 9.9.9.9 || 208.67.222.222
|-
|-
| Priority || 254 || 255
| Priority || 254 || 255
Zeile 132: Zeile 133:
* Die niedrigere '''Priority''' gewinnt bei der Wahl des Default-Gateways. Stehen beide auf 255,
* Die niedrigere '''Priority''' gewinnt bei der Wahl des Default-Gateways. Stehen beide auf 255,
   ist die Wahl zufällig.
   ist die Wahl zufällig.
=== Nun zuordnen der Gateway in den Interface Sektionen ===
{| class="wikitable"
! Interface !! IPv4 gateway rules
|-
| WAN1 || WAN1GW
|-
| WAN2 || WAN2GW
|}
===Wichtig===
'''Die Gateways erscheinen in den Gateway Gruppen erstnach einem Neustart der opnsense'''


=== Einstellen der Gatewaygruppe ===
=== Einstellen der Gatewaygruppe ===
Zeile 142: Zeile 155:
| Group Name || GW_GROUP
| Group Name || GW_GROUP
|-
|-
| Gateway Priority || GW1 = Tier 1, GW2 = Tier 2
| Gateway Priority || WAN1GW = Tier 1, WAN2GW = Tier 2
|-
|-
| Trigger Level || '''Member Down'''
| Trigger Level || '''Member Down'''
Zeile 152: Zeile 165:
! Ziel !! Tier-Vergabe !! Trigger Level
! Ziel !! Tier-Vergabe !! Trigger Level
|-
|-
| Failover (Standard hier) || GW1 = Tier 1, GW2 = Tier 2 || Member Down
| Failover (Standard hier) || WAN1GW = Tier 1, WAN2GW = Tier 2 || Member Down
|-
|-
| Lastverteilung || beide Tier 1 || Packet Loss or High Latency
| Lastverteilung || beide Tier 1 || Packet Loss or High Latency
Zeile 167: Zeile 180:
! DNS Server !! Use gateway
! DNS Server !! Use gateway
|-
|-
| 9.9.9.9 || GW1 – opt3 – 10.88.1.1
| 8.8.8.8 || WAN1GW
|-
|-
| 1.0.0.1 || '''GW2 – opt2 – 10.99.99.1'''
| 1.1.1.1 || WAN2GW
|}
|}


Zeile 178: Zeile 191:
=== NAT auf beiden WAN-Interfaces ===
=== NAT auf beiden WAN-Interfaces ===


''Firewall: NAT: Outbound''
''Firewall: NAT: Outbound'' – manuelle Regeln (Protokoll und Ports jeweils <code>*</code>, IPv4)


{| class="wikitable"
{| class="wikitable"
! Feld !! Wert
! # !! Interface !! Source !! Destination !! Translate / target !! Beschreibung
|-
| 1 || WAN1 || LAN network || * || Interface address || LAN ins Internet
|-
|-
| Mode || '''Hybrid outbound NAT rule generation'''
| 2 || WAN2 || LAN network || * || Interface address || LAN ins Internet
|}
|}


{| class="wikitable"
Das Ausrufezeichen vor dem Zielnetz invertiert die Bedingung: Die Regel greift für alle Ziele
! Interface !! Source !! Source Port !! Destination !! Dest. Port !! NAT Address !! NAT Port !! Static Port
'''außer''' <code>10.88.0.0/16</code>. Verkehr aus der DMZ zu den übrigen internen Netzen wird
|-
also nicht übersetzt und behält seine Quelladresse – nur so bleiben Logs und Firewallregeln
| WAN1 || LAN net || * || * || * || Interface address || * || NO
auf den Zielsystemen auswertbar.
|-
| WAN2 || LAN net || * || * || * || Interface address || * || NO
|}


'''Warum Hybrid statt Manual:''' Im Modus ''Manual'' verschwinden alle automatisch erzeugten
''Jede Regel existiert doppelt, einmal je WAN-Interface. Das ist bei Multiwan zwingend: Welche
Regeln – also auch NAT für VPN-Netze, für die Firewall selbst (Loopback) und die Static-Port-Regel
Leitung genutzt wird, entscheidet das Policy Routing der Firewallregel; die passende NAT-Regel
für ISAKMP (UDP 500). Hybrid behält die automatischen Regeln und stellt die eigenen davor.
muss auf beiden Wegen bereitstehen.''
Wer bewusst ''Manual'' fahren will, muss zusätzlich Regeln für alle weiteren internen Netze
(DMZ, VPN) und <code>127.0.0.0/8</code> anlegen.


=== Firewallregeln mit Gateway-Gruppe ===
=== Firewallregeln mit Gateway-Gruppe ===
Zeile 205: Zeile 215:


{| class="wikitable"
{| class="wikitable"
! # !! Action !! Source !! Destination !! Gateway !! Zweck
! # !! Action !! Source !! Destination !! Gateway !! Description
|-
|-
| 1 || Pass || LAN net || This Firewall || ''leer (default)'' || DNS, NTP, Web-GUI
| 1 || Pass || LAN net || This Firewall || ''leer (default)'' || Ziel Firewall
|-
|-
| 2 || Pass || LAN net || Alias LOKALE_NETZE || ''leer (default)'' || interne Netze, DMZ, VPN
| 2 || Pass || LAN net || LAN net || ''leer (default)'' || Ziel LAN
|-
|-
| 3 || Pass || LAN net || any || '''GW_GROUP''' || Internetverkehr über die Gruppe
| 3 || Pass || LAN net || any || '''GW_GROUP''' || Ziel Internet
|}
|}


Zeile 240: Zeile 250:
|}
|}


'''Der klassische Fehler:''' Nur eine einzige Regel mit Gateway GW_GROUP. Eine Gateway-Angabe
'''Der klassische Fehler:''' Nur die eine Regel mit Gateway GW_GROUP anlegen. Eine Gateway-Angabe
erzwingt Policy Routing für ''alles'', was auf die Regel passt – auch für Pakete an die DMZ, an
erzwingt Policy Routing für ''alles'', was auf die Regel passt – auch für Pakete an die Firewall
VPN-Gegenstellen und an die Firewall selbst. Diese Pakete werden dann in Richtung Internet
selbst. Diese Pakete werden dann in Richtung Internet geschickt und verschwinden. Deshalb müssen
geschickt und verschwinden. Deshalb müssen die Regeln 1 und 2 ''ohne'' Gateway-Angabe darüber
die Regeln 1 und 2 ''ohne'' Gateway-Angabe darüber stehen.
stehen.


Der Alias <code>LOKALE_NETZE</code> (''Firewall: Aliases'', Typ Network) enthält alle eigenen
''Bei mehreren internen Netzen (DMZ, VLANs, VPN) legt man dafür einen Alias''
Netze, z. B. die LAN-, DMZ- und VPN-Bereiche.
<code>LOKALE_NETZE</code> ''an und verwendet ihn auf jedem internen Interface in einer Regel
ohne Gateway-Angabe oberhalb der Internet-Regel.''


=== Firewall: Settings: Advanced ===
=== Firewall: Settings: Advanced ===
Zeile 260: Zeile 270:


== Szenarien testen ==
== Szenarien testen ==
* curl -4 --interface em1 ifconfig.co
* curl -4 --interface em4 ifconfig.co


{| class="wikitable"
{| class="wikitable"
! Szenario !! Vorgehen !! Erwartetes Ergebnis
! Szenario !! Vorgehen !! Erwartetes Ergebnis
|-
|-
| Normalbetrieb || <code>traceroute 9.9.9.9</code> vom Client || erster Hop 10.88.1.1 (GW1)
| Normalbetrieb || <code>traceroute 9.9.9.9</code> vom Client || erster Hop 192.168.HS.254 (WAN1GW)
|-
|-
| Ausfall WAN1 || Kabel in VirtualBox trennen || Dashboard zeigt GW1 offline, Verkehr läuft über 10.99.99.1
| Ausfall WAN1 || Kabel in VirtualBox trennen || Dashboard zeigt WAN1GW offline, Verkehr läuft über 172.30.34.254
|-
|-
| Rückkehr WAN1 || Kabel wieder verbinden || GW1 wieder online, neue Verbindungen laufen über GW1
| Rückkehr WAN1 || Kabel wieder verbinden || WAN1GW wieder online, neue Verbindungen laufen über WAN1GW
|-
|-
| DNS-Test || <code>dig @9.9.9.9</code> und <code>dig @1.0.0.1</code> || beide antworten, jeder über seine Leitung
| DNS-Test || <code>dig @8.8.8.8</code> und <code>dig @1.1.1.1</code> || beide antworten, jeder über seine Leitung
|-
|-
| Zugriff intern || Ping in DMZ bei totem WAN1 || funktioniert weiter (Regel 2 ohne Gateway)
| Zugriff Firewall || Ping auf die LAN-Adresse der Firewall bei totem WAN1 || funktioniert weiter (Regel 1 ohne Gateway)
|}
|}


Aktuelle Version vom 28. Oktober 2026, 17:15 Uhr

Ausgangspunkt

  • Diese Übung beginnt auf einer frisch aus dem ausgegebenen OPNsense-Template geklonten Firewall, ohne Reste aus früheren Übungen (NAT, Regeln, Bridges, VPN).
  • Beim Klonen neue MAC-Adressen für alle Netzwerkkarten erzeugen.
  • HA und Multi-WAN werden nicht kombiniert: jede Übung bekommt ihre eigene frische Firewall.

Plan

OPNsense Multiwan
Rolle Interface Gerät Identifier IP-Adresse Provider-Gateway
Internes Netz LAN em0 lan LAN-Netz/24 –
Provider A WAN1 em1 opt2 192.168.HS.2XX/24 192.168.HS.254
Provider B WAN2 em4 opt4 172.30.34.2XX/24 172.30.34.254

Hinweis: Die Identifier (opt1, opt2, opt3 …) vergibt OPNsense in der Reihenfolge, in der die Interfaces angelegt werden. Sie müssen nicht fortlaufend zu den Gerätenamen passen – wichtig ist nur, dass sie in Gateways, DNS und Regeln konsistent referenziert werden.

Was müssen wir tun?

  • 2 WAN-Interfaces anlegen
  • 2 Gateways definieren
  • Eine Gatewaygruppe erstellen
  • Die Internetleitungen überwachen (Healthcheck über Monitor-IP)
  • Eine Entscheidungsinstanz schaffen: die Gatewaygruppe entscheidet über Tier und Trigger Level
  • Zuordnung klären: Policy Routing über die Gateway-Angabe in der Firewallregel
  • DNS-Server pro Leitung zuordnen
  • Firewallregeln anpassen (Reihenfolge beachten!)
  • NAT-Regeln anpassen
  • Szenarien testen

Konfiguration

Interface WAN1

Interfaces: [WAN1]

Feld Wert
Enable aktiv
Device em1
Description WAN1
Block private networks aus
Block bogon networks aus
IPv4 Configuration Type Static IPv4
IPv6 Configuration Type None
IPv4 address 192.168.HS.2XX/24
IPv4 Upstream Gateway hier kommt später WAN1GW rein

Wichtig: Die Präfixlänge /24 darf nicht fehlen, sonst wird das Interface mit /32 angelegt und das Gateway ist nicht erreichbar.

Interface WAN2

Interfaces: [WAN2]

Feld Wert
Enable aktiv
Device em4
Description WAN2
Block private networks aus
Block bogon networks aus
IPv4 Configuration Type Static IPv4
IPv6 Configuration Type None
IPv4 address 172.30.34.2XX/24
IPv4 Upstream Gateway hier kommt später WAN2GW rein

Einstellen der Gateways

System: Gateways: Configuration

Feld GW1 GW2
Name WAN1GW WAN2GW
Interface WAN1 WAN2
Address Family IPv4 IPv4
IP Address 192.168.HS.254 172.30.34.254
Upstream Gateway aktiv aktiv
Far Gateway aus aus
Disable Gateway Monitoring aus aus
Monitor IP 9.9.9.9 208.67.222.222
Priority 254 255

Zwei Punkte, die häufig falsch gemacht werden:

  • Upstream Gateway muss bei beiden Gateways gesetzt sein. Es kennzeichnet ein Gateway als
 Internet-Ausgang; ist es nur bei einem gesetzt, verhält sich das Failover unvorhersehbar.
  • Die Monitor-IPs müssen bei verschiedenen Betreibern liegen und dürfen nicht mit den
 DNS-Servern identisch sein. 8.8.8.8 und 8.8.4.4 gehören beide Google: fällt Google aus, werden
 beide Leitungen als tot gemeldet. Für jede Monitor-IP legt OPNsense zusätzlich eine Hostroute über
 das jeweilige Gateway an; benutzt man dieselbe IP auch als DNS-Server, überlagern sich Hostroute
 und DNS-Zuordnung.
  • Die niedrigere Priority gewinnt bei der Wahl des Default-Gateways. Stehen beide auf 255,
 ist die Wahl zufällig.

Nun zuordnen der Gateway in den Interface Sektionen

Interface IPv4 gateway rules
WAN1 WAN1GW
WAN2 WAN2GW

Wichtig

Die Gateways erscheinen in den Gateway Gruppen erstnach einem Neustart der opnsense

Einstellen der Gatewaygruppe

System: Gateways: Group

Feld Wert
Group Name GW_GROUP
Gateway Priority WAN1GW = Tier 1, WAN2GW = Tier 2
Trigger Level Member Down
Pool Options Default
Ziel Tier-Vergabe Trigger Level
Failover (Standard hier) WAN1GW = Tier 1, WAN2GW = Tier 2 Member Down
Lastverteilung beide Tier 1 Packet Loss or High Latency

Bei Lastverteilung zusätzlich Firewall: Settings: Advanced → Sticky connections aktivieren, sonst wechseln einzelne Verbindungen desselben Clients die Leitung.

DNS pro Leitung

System: Settings: General

DNS Server Use gateway
8.8.8.8 WAN1GW
1.1.1.1 WAN2GW
  • Prefer IPv4 over IPv6: aktiv
  • Die Zuordnung sorgt dafür, dass jeder DNS-Server über „seine“ Leitung befragt wird. Fällt eine
 Leitung aus, bleibt der andere Resolver erreichbar.

NAT auf beiden WAN-Interfaces

Firewall: NAT: Outbound – manuelle Regeln (Protokoll und Ports jeweils *, IPv4)

# Interface Source Destination Translate / target Beschreibung
1 WAN1 LAN network * Interface address LAN ins Internet
2 WAN2 LAN network * Interface address LAN ins Internet

Das Ausrufezeichen vor dem Zielnetz invertiert die Bedingung: Die Regel greift für alle Ziele außer 10.88.0.0/16. Verkehr aus der DMZ zu den übrigen internen Netzen wird also nicht übersetzt und behält seine Quelladresse – nur so bleiben Logs und Firewallregeln auf den Zielsystemen auswertbar.

Jede Regel existiert doppelt, einmal je WAN-Interface. Das ist bei Multiwan zwingend: Welche Leitung genutzt wird, entscheidet das Policy Routing der Firewallregel; die passende NAT-Regel muss auf beiden Wegen bereitstehen.

Firewallregeln mit Gateway-Gruppe

Firewall: Rules: LAN – die Reihenfolge ist entscheidend:

# Action Source Destination Gateway Description
1 Pass LAN net This Firewall leer (default) Ziel Firewall
2 Pass LAN net LAN net leer (default) Ziel LAN
3 Pass LAN net any GW_GROUP Ziel Internet

Regel 3 im Detail:

Feld Wert
Action Pass
Quick aktiv
Interface LAN
Direction in
TCP/IP Version IPv4
Protocol any
Source LAN net
Destination any
Description LAN to any über Gateway-Gruppe
Gateway GW_GROUP

Der klassische Fehler: Nur die eine Regel mit Gateway GW_GROUP anlegen. Eine Gateway-Angabe erzwingt Policy Routing für alles, was auf die Regel passt – auch für Pakete an die Firewall selbst. Diese Pakete werden dann in Richtung Internet geschickt und verschwinden. Deshalb müssen die Regeln 1 und 2 ohne Gateway-Angabe darüber stehen.

Bei mehreren internen Netzen (DMZ, VLANs, VPN) legt man dafür einen Alias LOKALE_NETZE an und verwendet ihn auf jedem internen Interface in einer Regel ohne Gateway-Angabe oberhalb der Internet-Regel.

Firewall: Settings: Advanced

Option Empfehlung Wirkung
Skip rules when gateway is down aktiv Bei totem Gateway wird die Regel entfernt statt auf das Default-Gateway zurückzufallen – verhindert stillen Rückfall auf die falsche Leitung
Sticky connections nur bei Lastverteilung hält alle Verbindungen eines Clients auf derselben Leitung

Szenarien testen

  • curl -4 --interface em1 ifconfig.co
  • curl -4 --interface em4 ifconfig.co
Szenario Vorgehen Erwartetes Ergebnis
Normalbetrieb traceroute 9.9.9.9 vom Client erster Hop 192.168.HS.254 (WAN1GW)
Ausfall WAN1 Kabel in VirtualBox trennen Dashboard zeigt WAN1GW offline, Verkehr läuft über 172.30.34.254
Rückkehr WAN1 Kabel wieder verbinden WAN1GW wieder online, neue Verbindungen laufen über WAN1GW
DNS-Test dig @8.8.8.8 und dig @1.1.1.1 beide antworten, jeder über seine Leitung
Zugriff Firewall Ping auf die LAN-Adresse der Firewall bei totem WAN1 funktioniert weiter (Regel 1 ohne Gateway)

Statusanzeigen: Lobby: Dashboard (Widget Gateways), System: Gateways: Log File sowie Interfaces: Diagnostics: Routes.

Umsetzung

Abgerufen von „https://wiki.ixheim.de/index.php?title=OPNsense_2_Provider&oldid=73972“