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?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1220415071
Url: https://administrator.de/forum/opnsense-wireguard-site2site-und-firewallregeln-fuer-remotenetz-1220415071.html
Ausgedruckt am: 23.12.2024 um 01:12 Uhr
7 Kommentare
Neuester Kommentar
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 !
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...