7
OPNSense, WireGuard Site2Site und Firewallregeln für Remotenetz
Hallo zusammen,
ich habe hier kürzlich einen Beitrag zu Problemen mit OPNSense, IPSEC und einer Fritz!Box 7590 gepostet (Seltstames Phänomen: OPNSense - Fritz!Box Lankopplung per IPSEC).
Da ich das IPSEC-Problem nicht lösen konnte, habe das VPN-Protokoll auf WireGuard geändert und bin mit dem Ergebnis bzw. der Performance sehr zufrieden.
Es stellt sich jetzt nur eine Frage zu den Firewallregeln:
Im Gegensatz zu IPSEC benötigt WireGuard ein Transportnetz, sodass in meinem Fall das Netzwerk der Gegenseite über die IP-Adresse 10.7.0.2/32 im WireGuard-Tunnel verfügt und über den IP-Adressbereich 192.168.210.0/24 im eigentlichen Remote-Netz.
Wenn ich in der OPNSense-Firewall-Regeln einschränke, dann ist mir das bisher nur für das komplette Remote-Netz gelungen, indem ich unter dem automatisch angelegten WireGuard-Interface entsprechende Einschränkungen für die IP-Adresse 10.70.2/32 gemacht habe (die in diesem Fall mein komplettes Remote-Netz repräsentiert). Wie kann ich es jedoch erreichen, dass ich nur bestimmte Clients aus dem eigentlichen Remote-Netz 192.168.210.0/24 (bspw. 192.168.210.20/32) zulasse?
Ich habe hierfür zwar mal testweise eine eigene Schnittstelle für den Wireguard-Tunnel (WG0_KA) in der OPNSense angelegt und hier versucht, dem Raspi aus dem Remote-Netz auf einzelne Clients im LAN 192.168.100.0/24 RDP-Zugriff zu geben, aber das hat nicht funktioniert. Entweder konnte er nur auf die Clients zugreifen, für die ein Zugriff im WireGuard-Interface aus dem Netzbereich 10.7.0.0/24 erlaubt war, oder auf gar keine (als ich testweise eine Sperrregel für alle Clients aus dem Netzbereich 192.168.210.0/24 angelegt hatte).
Anbei der Plan zum Netzwerkaufbau:
Im Remote-Netz 192.168.210.0/24 dient ein Raspi (192.168.210.20/0) als VPN-Router, für den ich in der Fritz!Box 192.168.210.254/24 zwei Routen angelegt habe (10.7.0.0/24 und 192.168.100.0/24 jeweils über 192.168.210.20). Es wird im Tunnel also nicht genattet.
Hat hier jemand eine Idee bzw. ein Tipp?
ich habe hier kürzlich einen Beitrag zu Problemen mit OPNSense, IPSEC und einer Fritz!Box 7590 gepostet (Seltstames Phänomen: OPNSense - Fritz!Box Lankopplung per IPSEC).
Da ich das IPSEC-Problem nicht lösen konnte, habe das VPN-Protokoll auf WireGuard geändert und bin mit dem Ergebnis bzw. der Performance sehr zufrieden.
Es stellt sich jetzt nur eine Frage zu den Firewallregeln:
Im Gegensatz zu IPSEC benötigt WireGuard ein Transportnetz, sodass in meinem Fall das Netzwerk der Gegenseite über die IP-Adresse 10.7.0.2/32 im WireGuard-Tunnel verfügt und über den IP-Adressbereich 192.168.210.0/24 im eigentlichen Remote-Netz.
Wenn ich in der OPNSense-Firewall-Regeln einschränke, dann ist mir das bisher nur für das komplette Remote-Netz gelungen, indem ich unter dem automatisch angelegten WireGuard-Interface entsprechende Einschränkungen für die IP-Adresse 10.70.2/32 gemacht habe (die in diesem Fall mein komplettes Remote-Netz repräsentiert). Wie kann ich es jedoch erreichen, dass ich nur bestimmte Clients aus dem eigentlichen Remote-Netz 192.168.210.0/24 (bspw. 192.168.210.20/32) zulasse?
Ich habe hierfür zwar mal testweise eine eigene Schnittstelle für den Wireguard-Tunnel (WG0_KA) in der OPNSense angelegt und hier versucht, dem Raspi aus dem Remote-Netz auf einzelne Clients im LAN 192.168.100.0/24 RDP-Zugriff zu geben, aber das hat nicht funktioniert. Entweder konnte er nur auf die Clients zugreifen, für die ein Zugriff im WireGuard-Interface aus dem Netzbereich 10.7.0.0/24 erlaubt war, oder auf gar keine (als ich testweise eine Sperrregel für alle Clients aus dem Netzbereich 192.168.210.0/24 angelegt hatte).
Anbei der Plan zum Netzwerkaufbau:
Im Remote-Netz 192.168.210.0/24 dient ein Raspi (192.168.210.20/0) als VPN-Router, für den ich in der Fritz!Box 192.168.210.254/24 zwei Routen angelegt habe (10.7.0.0/24 und 192.168.100.0/24 jeweils über 192.168.210.20). Es wird im Tunnel also nicht genattet.
Hat hier jemand eine Idee bzw. ein Tipp?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1220415071
Url: https://administrator.de/contentid/1220415071
Printed on: April 28, 2024 at 22:04 o'clock
7 Comments
Latest comment
Da ich das IPSEC-Problem nicht lösen konnte,
Ooops...!!! Warum das ?? Ist eigentlich kinderleicht auch für einen Laien ! Guckst du hier:Fritzbox 7590 x opnsense
Wie kann ich es jedoch erreichen, dass ich nur bestimmte Clients aus dem eigentlichen Remote-Netz 192.168.210.0/24 (bspw. 192.168.210.20/32) zulasse?
Du filterst NICHT im Wireguard Netz, denn das ist ja nur Transportnetz. Die Absender- und Zieladressen im IP Paket sind doch immer einzig nur die des lokalen LANs. Hier machst du vermutlich einen Denkfehler ?!Man kann zwar auch an den WG Interfaces filtern aber das macht ja wenig Sinn weil du dann Pakete die du eigentlich nicht haben willst schon "in" der Firewall drin hast.
Grundsätzlich gelten die 2 Grundregeln:
- Regeln wirken immer nur INBOUND. Also VOM Netzwerk Draht IN das Interface hinein (OPNsense kann auch outbound was dann aber auf die Performance geht da Forwarding dann in CPU und man hat die Pakete ja wieder in der der Firewall die man nicht will. Deshalb sollte man Outbound Filterung generell vermeiden wenn immer möglich !)
- Es gilt "First match wins !" Sprich also der erste positive Hit im Regelwerk bewirt das nachfolgende Regeln NICHT mehr abgearbeitet werden. Reihenfolge zählt also.
Netzwerke:
- lokale FW LAN IP Netz = 192.168.100.0 /24
- remote FW LAN IP Netz = 192.168.210.0 /24
- Host .210.20 im remoten Netz darf nur von Host .100.100 erreicht werden
Regelbeispiel 1:
PASS: IPv4, Source: 192.168.100.100, Port: any, Destination: 192.168.210.20, Port: any
BLOCK: IPv4, Source: 192.168.100.0, Port: any, Destination: 192.168.210.0, Port: any
PASS: IPv4, Source: 192.168.100.0, Port: any, Destination: any, Port: any
Regelbeispiel 2:
(Host darf anderen nur mit OpenVPN UDP 1194 erreichen)
PASS: UDPv4, Source: 192.168.100.100, Port: any, Destination: 192.168.210.20, Port: 1194
BLOCK: IPv4, Source: 192.168.100.0, Port: any, Destination: 192.168.210.0, Port: any
PASS: IPv4, Source: 192.168.100.0, Port: any, Destination: any, Port: any
Regelbeispiel 3:
(Host darf anderen nur mit SSH und OpenVPN UDP 1194 erreichen)
PASS: UDPv4, Source: 192.168.100.100, Port: any, Destination: 192.168.210.20, Port: 1194
PASS: TCPv4, Source: 192.168.100.100, Port: any, Destination: 192.168.210.20, Port: 22
BLOCK: IPv4, Source: 192.168.100.0, Port: any, Destination: 192.168.210.0, Port: any
PASS: IPv4, Source: 192.168.100.0, Port: any, Destination: any, Port: any
Das einfache Prinzip des Regelwerkes wird dir vermutlich anhand der 3 Beispiele sofort klar ?!
Du solltest dir auch angewöhnen TCP und UDP auch nur da zu verwenden wenn Protokolle das eine oder das andere verwenden und nicht schrotschussartig immer beides für die Ports freizugeben. HTTP z.B. nutzt niemals UDP und Wireguard selber nutzt niemals TCP ! Auch das macht eine Firewall unsicher und führt sie letztlich ad absurdum !
Hallo aqui,
Du hast Recht, dass ich mich gedanklich noch an die Wege von Paketen in einer Firewall gewöhnen muss und vielen Dank für den Tipp mit der Unterscheidung nach UDP und TCP je Anwendungsfall.
Ich denke, ich habe Dein Beispiel verstanden, wobei es in diesem Fall für mich gedanklich die einfachere Variante war, da in Deinem Beispiel die Pakete aus dem lokalen LAN 100.0 in Richtung Remote-Netzwerk 210.0 gehen. Hier ist das Interface für die eingehenden Regeln das LAN-Interface der OPNSense. Mein Anwendungsszenario ja umgekehrt, da Clients aus dem Remote-Netz 210.0 nur auf bestimmte Clients im lokalen LAN 100.0 zugreifen sollen.
Ich habe jetzt nochmals getetest und habe die Lösung auch dank Deiner Info gefunden:
Wenn ich im WireGuard-Interface Regeln für das Transportnetz bspw. 10.7.0.2/32 anlege, dann gelten die für alle Clients des dahinter stehenden Netzes 192.168.210.0 und werden als erstes verarbeitet, sodass nachfolgende Regeln im WG0-Interface nicht mehr berücksichtigt werden.
Wenn ich bspw. im übergeordneten Wireguard-Interface gar keine Regeln anlege, dann kann ich das komplette Subnetz 192.168.210.0/24 im WG0-Interface granular regeln und habe somit mein Ziel erreicht
.
Herzlichen Dank nochmals
Du hast Recht, dass ich mich gedanklich noch an die Wege von Paketen in einer Firewall gewöhnen muss und vielen Dank für den Tipp mit der Unterscheidung nach UDP und TCP je Anwendungsfall.
Ich denke, ich habe Dein Beispiel verstanden, wobei es in diesem Fall für mich gedanklich die einfachere Variante war, da in Deinem Beispiel die Pakete aus dem lokalen LAN 100.0 in Richtung Remote-Netzwerk 210.0 gehen. Hier ist das Interface für die eingehenden Regeln das LAN-Interface der OPNSense. Mein Anwendungsszenario ja umgekehrt, da Clients aus dem Remote-Netz 210.0 nur auf bestimmte Clients im lokalen LAN 100.0 zugreifen sollen.
Ich habe jetzt nochmals getetest und habe die Lösung auch dank Deiner Info gefunden:
Wenn ich im WireGuard-Interface Regeln für das Transportnetz bspw. 10.7.0.2/32 anlege, dann gelten die für alle Clients des dahinter stehenden Netzes 192.168.210.0 und werden als erstes verarbeitet, sodass nachfolgende Regeln im WG0-Interface nicht mehr berücksichtigt werden.
Wenn ich bspw. im übergeordneten Wireguard-Interface gar keine Regeln anlege, dann kann ich das komplette Subnetz 192.168.210.0/24 im WG0-Interface granular regeln und habe somit mein Ziel erreicht
.Herzlichen Dank nochmals
Mein Anwendungsszenario ja umgekehrt,
Ist ja nur Kosmetik in der IP Adressierung... 
dann kann ich das komplette Subnetz 192.168.210.0/24
Das kannst (und solltest) du aber besser direkt am .210.0er LAN Interface gleich regeln. Das bewirkt dann das die entsprechenden IP Pakete gleich direkt außen vor bleiben.Der gravierende Nachteil der Filterung auf dem wg0 Interface ist ja das das Paket schon "in" der Firewall drin ist also Regel- und IP Forwarding technisch schon Durchsatz und Performance gekostet hat was du ja eigentlich nicht willst. Deshalb ist es immer sinnvoller gleich in der Peripherie am INBOUND Interface zu blocken.
Kleiner Tip noch was die IP Adressierung betrifft:
Nutze einfach mal die Paket Capture Funktion an der Firewall oder direkt den Wireshark und sieh dir den Traffic mal an. Im Wireshark kann man hervorragend den Aufbau der IP Pakete mit den Absender und Zieladressen und der verwendeten Ports sehen. Das erleichtert ungemein das Verständnis auch für die FW Regelwerke.
https://www.heise.de/ct/artikel/Fehler-erschnueffeln-221587.html
Herzlichen Dank nochmals
Immer gerne...
Hmm, dann habe ich doch noch eine Rookie-Frage zum Verständnis: Was meinst Du mit 210er-LAN-Interface?
Meinst Du damit, dass ich die Pakete schon im Remote-Netzwerk mit der Fritz!Box stoppen soll, sodass die dort gar nicht erst in den WireGuard Tunnel gehen?
Auf meiner LAN-Seite habe ich gedanklich folgenden Weg für die eingehenden Pakete:
WAN-Interface mit externer IP - WireGuard-Interface 10.7.0.0 - WG0-Interface - LAN.
Liege ich damit richtig und wenn ja, welche Schnittstelle wäre die notwendige für die Filterung?
Meinst Du damit, dass ich die Pakete schon im Remote-Netzwerk mit der Fritz!Box stoppen soll, sodass die dort gar nicht erst in den WireGuard Tunnel gehen?
Auf meiner LAN-Seite habe ich gedanklich folgenden Weg für die eingehenden Pakete:
WAN-Interface mit externer IP - WireGuard-Interface 10.7.0.0 - WG0-Interface - LAN.
Liege ich damit richtig und wenn ja, welche Schnittstelle wäre die notwendige für die Filterung?
Was meinst Du mit 210er-LAN-Interface?
Den Firewall Port an dem das .210.0er Netz dranhängt. sodass die dort gar nicht erst in den WireGuard Tunnel gehen?
Richtig !Immer direkt da filtern wo diese Pakete in die Firewall zuallererst "reinkommen".
Klasse,dann habe ich es jetzt verstanden .
.
👍
