OPNsense Forum
International Forums => German - Deutsch => Topic started by: opnboi on February 09, 2021, 12:48:10 pm
-
Hallo zusammen,
nach der quasi problemlesen Migration zur OPNsense gibt es ein paar kleine Hürden, die aber vermutlich mit Hilfe des Forum leicht zu meistern sind;)
Im Anhang seht ihr ein ungefähren Plan des Netzwerks bzw. der 2 Netzwerke.
Nun zum Problem bzw. den Problemen:
1. Im internen Netz 192.168.65.0 komme ich via dem IPSec Site2Site Tunnel problemlos zur entfernten FritzBox! 192.168.1.100 - so weit so gut :)
Verbinde ich mich mit dem Smartphone von außerhalb via WireGuard Roadwarrior zur OPNsense, komme ich dank Regeln ins lokale Netz (192.168.65.0) und erreiche hier alles. Die 2. Config, dass aller Traffic durch den Tunnel geht funktioniert auch.
Was nicht funktioniert, ist der Zugriff via WireGuard Roadwarrior auf das entfernte Netz (192.168.1.0).
In den Firewall-Logs ist auch zu sehen, dass der Zugriff via WireGuard aufs lokale LAN vom LAN Interface kommt und durchgeht, beim Zugriff auf die 192.168.1.100 jedoch über das WAN Interface durchgeht, was ja logisch erscheint.
Muss jetzt hier in der OPNsense oder auf der entfernten FritzBox noch was angepasst werden?
Vermutlich ist es nur eine kleine Regel, aber manchmal sieht man den Wald vor lauter Bäumen nicht;)
Zum 2. Problem: Dies hat nur inderekt was mit OPNsense zu tun, tritt aber auch erst jetzt mit dem Wechsel auf WireGuard auf....
Ich nutze für die schnelle Verwaltung der beiden FritzBoxen auf dem Smartphone die App "BoxToGo Pro" - befinde ich mich im lokalen (W)LAN, klappt der Zugriff auf beiden FritzBoxen auch - sobald ich mich als Roadwarrior von außerhalb verbinde, bekomme von der App die Meldung, dass die Zugangsdaten falsch sind :o
Was ja definitiv nicht der Fall ist, da sie ja lokal im WLAN funktionieren ;)
Was macht hier WireGuard also mit den Paketen? ???
Hat jemand eine Idee was die beiden "Probleme" angeht?
Beste Grüße
-
Ist denn das WireGuard Netz in der Phase2 vom IPsec Tunnel vermerkt? Du brauchst m.E. noch einen Phase2 Eintrag. Jede mögliche Kombination aus Netzen muss dort eingetragen sein (bei Policy based).
-
Hallo,
danke für deine Antwort:)
Nein, dass WireGuard Netz ist nicht im IPsec Tunnel vermerkt - müsste ja dann auf beiden Seiten (Remote FritzBox + OPNSense ) eingetragen werden oder?
-
Genau
-
Dachte ich mir...
Nun die "doofe" Frage, muss das WireGuard Netz in die Configdatei für die FritzBox in einen separaten Phase2-Eintrag oder in den schon vorhandenen rein?
phase2localid {
ipnet {
ipaddr = 192.168.1.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.65.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs";
accesslist = "permit ip any 192.168.65.0 255.255.255.0";
Edit:
Habs jetzt wie hier angepasst:
https://www.linogate.de/de/support/categories/ipsec/fritzbox.html
Klappt aber trotzdem nicht:/
Ich sehe in den Firewall-Logs, dass der Traffic via IPsec Interface zur entfernten FritzBox geht, aber von dort kommt scheinbar nix zurück...
Hat noch jemand eine Idee?
-
Ich antworte jetzt mal...
Es funktioniert - Lösung sogar hier im Forum:
https://forum.opnsense.org/index.php?topic=9222.0
Habe also die vpn.cfg für die FritzBox angepasst und das WireGuard-Netz allein unter Manual SPD entries eingetragen :)
Jetzt bleibt nur noch die Frage, warum das mit BoxToGo nicht klappt...
Sollte ich das "Problem" in einen separten Thread auslagern?
-
Setze dann das Thema mal wieder auf "UNSOLVED" :-\
Es geht nicht mehr - am IPsec Tunnel wurde nichts verändert - aber der Traffic zur entfernten FritzBox geht jetzt wieder über das WG Interface statt über das IPsec Interface
Manche Dinge muss man nicht verstehen oder?
-
Da mir die OPNsense heute neben dem IPsec Problem auch instabil vorkam - Zugang zum Internet war mehrmals weg - habe ich eben ein Downgrade auf 21.1 gemacht.
Hatte ja gestern quasi alles wie gewünscht zum Laufen bekommen und vorm Update ein Backup angelegt, konnte jetzt aber mit "opnsense-revert -r 21.1 opnsense" auf die 21.1 zurückgehen und voila, ich komme via WireGuard in das entfernte Subnet :)
Fragt sich nur was hiervon "gestört" hat...
firewall: change order of shaper delay parameter to prevent parser errors
firewall: fix multiple PHP warnings regarding category additions
firewall: fix icon toggle for block and reject (contributed by ElJeffe)
interfaces: unhide primary IPv6 in overview page
interfaces: fix IPv6 misalignment in get_interfaces_info()
reporting: fix sidebar menu collapse for NetFlow link (contributed by Maurice Walker)
captive portal: validate that static IP address exists when writing the configuration
firmware: add product status backend for upcoming firmware page redesign
firmware: opnsense-code will now check out the default release branch
firmware: opnsense-update adds “-R” option for major release selection
firmware: opnsense-update will now update repositories if out of sync
firmware: opnsense-update will attempt to recover from fatal pkg behaviour
firmware: opnsense-update now correctly redirects stderr on major upgrades
firmware: opnsense-update now retains vital flag on faulty release type transition
intrusion detection: clean up rule based additions to prevent collisions with the new policies
monit: minor bugfixes and UI changes (contributed by Manuel Faux)
unbound: update documentation URL (contributed by xorbital)
ui: format packet count with toLocaleString() in interface statistics widget (contributed by bleetsheep)
ui: add compatibility for JS replaceAll() function
rc: support reading JSON metadata from plugin version files
plugins: provide JSON metadata in plugin version files
plugins: os-dyndns GratisDNS apex domain fix (contributed by Fredrik Rambris)
plugins: os-nginx upstream TLS verification fix (contributed by kulikov-a)
plugins: os-theme-cicada 1.26 (contributed by Team Rebellion)
plugins: os-theme-vicuna 1.2 (contributed by Team Rebellion)
src: panic when destroying VNET and epair simultaneously [1]
src: uninitialized file system kernel stack leaks [2]
src: Xen guest-triggered out of memory [3]
src: update timezone database information [4]
ports: dnsmasq 2.84 [5]
ports: lighttpd 1.4.59 [6]
ports: krb5 1.19 [7]
ports: monit 5.27.2 [8]
ports: perl 5.32.1 [9]
ports: sqlite 3.34.1 [10]
-
So, ich antworte mir mal wieder selbst :-X
Es ist wie verhext, nachdem es gestern nachdem Downgrade auf die 21.1 erstmal wieder lief, klappt es jetzt wieder nicht mehr...
Es gab gestern Abend im (W)LAN dann noch DNS Probleme, dass praktisch keine Verbindung ins Internet möglich war, und selbst von einem Notebook im WLAN konnte ich nicht auf die GUI der OPNsense zugreifen (ping war aber möglich).
Heute morgen war dann der Zugriff von dem besagten Notebook auf die GUI wieder möglich, aber der Traffic vom WireGuard VPN zur entfernten FritzBox geht wieder über das WG und nicht über das IPsec Interface ::)
Wird denn in den IPsec Logs der SPD entry mit angezeigt?
Sehe für Phase2 nur diesen Eintrag:
2021-02-11T08:25:49 charon[60476] 04[IKE] <con1|2> CHILD_SA con1{4} established with SPIs cf64b319_i 1efd240e_o and TS 192.168.65.0/24 === 192.168.1.0/24
Weiterhin finde ich folgende Einträge in den Logs:
2021-02-11T08:32:14 charon[60476] 15[IKE] <con1|5> CHILD_SA not found, ignored
2021-02-11T08:32:14 charon[60476] 15[IKE] <con1|5> received DELETE for ESP CHILD_SA with SPI c8b996b3
2021-02-11T08:32:14 charon[60476] 15[ENC] <con1|5> parsed INFORMATIONAL_V1 request 2250304101 [ HASH D ]
2021-02-11T08:32:14 charon[60476] 15[NET] <con1|5> received packet: from 80.144.xxx.xxx[500] to 87.123.xxx.xxx[500] (124 bytes)
2021-02-11T08:32:14 charon[60476] 05[IKE] <con1|5> CHILD_SA not found, ignored
2021-02-11T08:32:14 charon[60476] 05[IKE] <con1|5> received DELETE for ESP CHILD_SA with SPI c5ebd422
2021-02-11T08:32:14 charon[60476] 05[ENC] <con1|5> parsed INFORMATIONAL_V1 request 3905009298 [ HASH D ]
2021-02-11T08:32:14 charon[60476] 05[NET] <con1|5> received packet: from 80.144.xxx.xxx[500] to 87.123.xxx.xxx1[500] (124 bytes)
2021-02-11T08:32:14 charon[60476] 05[IKE] <con1|5> CHILD_SA not found, ignored
2021-02-11T08:32:14 charon[60476] 05[IKE] <con1|5> received DELETE for ESP CHILD_SA with SPI cc920895
2021-02-11T08:32:14 charon[60476] 05[ENC] <con1|5> parsed INFORMATIONAL_V1 request 2279568483 [ HASH D ]
2021-02-11T08:32:14 charon[60476] 05[NET] <con1|5> received packet: from 80.144.xxx.xxx[500] to 87.123.xxx.xxx[500] (124 bytes)
2021-02-11T08:32:14 charon[60476] 05[IKE] <con1|5> CHILD_SA not found, ignored
2021-02-11T08:32:14 charon[60476] 05[IKE] <con1|5> received DELETE for ESP CHILD_SA with SPI 0d39f175
2021-02-11T08:32:14 charon[60476] 05[ENC] <con1|5> parsed INFORMATIONAL_V1 request 1055777905 [ HASH D ]
2021-02-11T08:32:14 charon[60476] 05[NET] <con1|5> received packet: from 80.144.xxx.xxx[500] to 87.123.xxx.xxx[500] (124 bytes)
2021-02-11T08:32:14 charon[60476] 05[NET] <con1|5> sending packet: from 87.123.xxx.xxx[500] to 80.144.xxx.xxx[500] (652 bytes)
Woher kommen aber bitte diese komischen DNS-Probleme von gestern Abend?
Bin kurz davor ein komplettes Rollback auf die 7490 zu machen ;D
-
So, nach einem Reboot der OPNsense wurde der Tunnel scheinbar wieder korrekt aufgebaut und der Traffic ging über das IPsec Interface (siehe Anhang "rw.png" - ebenso nach dem erneuten Upgrade auf 21.1.1.
Bis eben ::)
Jetzt gab es im lokalen (W)LAN wieder die DNS Probleme - Smartphone und Notebook sagen kein Zugriff ins Internet - und nach diesem kurzen "Schluckauf" geht auch wieder der Traffic nicht über das IPsec Interface, sondern über das WireGuard Interface - siehe "wg2.png" >:(
Nach einem Reboot der OPNsense geht es wieder - vermutlich aber nur bis zum nächsten "Schluckauf" ...
Was zum Geier ist hier los?
Das ist doch kein Zustand - ich bin kurz davor das ganze Ding platt zu machen und es zu verkaufen und die FritzBox wieder davor zu klemmen, denn so macht das einfach keinen Spass ::)
Hat jemand einen hilfreichen Tip?
Beste Grüße
-
Mal im Ernst: Das ist doch keine Migration, du hast einfach vor die Fritzpiepen auf einer Seite eine OPNsense geklemmt. Sowas kann kein Mensch remote debuggen, da müsste man alle Konfigurationsschritte kennen/nachvollziehen.
Entweder du machst wirklich die OPNsense zum Router/Firewall und nimmst die Fritzbox raus (oder machst sie ohne DHCP zum wifi ap) oder umgekehrt.
-
Wieso ist das keine Migration?
Wie würdest du es denn anstellen?
Die OPNsense ist doch Router und Firewall - die lokale FritzBox hängt hier als IP-Client hinter der OPNsense und macht WLAN und VoIP...
War das Netzdiagramm undeutlich?
-
mache es doch ganz einfach, deine fritzbox die das internet herstellt z. b. ip 192.168.64.1/24, deiner sense an dem wan port deine fritzbox (als wan), LAN Port der Sense 192.168.65.1/24. und den rest deines netzes an den lan port (mit einem switch und da auch die AP´s drann. z.b. siehe meinen netzwerk plan.
bei diesem aufbau sollte dir klar sein das dein wlan der fritzbox die dein internet herstellt nicht mehr benötigt wird.
-
Danke für die Antwort, ich möchte aber nicht, dass die FritzBox die Verbindung aufbaut - wozu habe ich mir denn dann den Vigor 165 gekauft?
Es ist doch quasi richtig eingerichtet und läuft auch alles, bis eben zu diesem "Schluckauf" den gilt es zu beseitigen...
-
in deinem netzwerkplan habe ich nichts von einem vigor gelesen, irgend wie nennts du hier hardware die in deinem plan nicht eingezeichnet sind.
-
Ups, der Vigor fehlt ja zwischen OPNsense und WAN - wird geändert :)
-
Danke für die Antwort, ich möchte aber nicht, dass die FritzBox die Verbindung aufbaut - wozu habe ich mir denn dann den Vigor 165 gekauft?
Es ist doch quasi richtig eingerichtet und läuft auch alles, bis eben zu diesem "Schluckauf" den gilt es zu beseitigen...
Vom Vigor hast Du bisher nichts erzählt und steht auch nichts im Netzwerkplan.
Ist der im Bridge-Mode?
Du sagtest doch, dass es schon mal funktioniert hat. Hilft ein Reboot der OPNsense kurzzeitig? Du kannst Dir die installierten SPD unter VPN: IPsec: Security Policy Database anzeigen lassen. Fehlt das Netzwerk da?
-
Jap sorry, hatte den Vigor im Netzwerkplan vergessen - ist jetzt aber drin und auch hier in dem Post mit angehangen.
Der Vigor läuft im FullBridge Modus - also nur als "dummes" Modem...
Genau, es funktioniert eine ganze Weile, bis es zu diesem omiösen "Schluckauf", wo der Zugang zum Internet für die Clients quasi ausfällt. Nach einem Reboot der OPNsense geht es erstmal wieder...
VPN: IPsec: Security Policy Database schaut momentan so aus --> Anhang VPN_SPD.png
Momentan klappt der Zugriff via WireGuard auch wie gewünscht...
-
Dann schau doch bitte nochmal wenn es nicht mehr geht, ob sich die Ansicht ändert.
-
Hätte ich nach deinem Hinweis mit dem SPD-Reiter auch gemacht :)
Nun heisst es warten 8)
Vermute aber mal ganz stark, dass der zweite Eintrag dann verschwunden ist...
Aber fällt dann kurzzeitig gleich das ganze DNS aus?
Ist im Unbound was falsch konfiguriert?
-
Hätte ich nach deinem Hinweis mit dem SPD-Reiter auch gemacht :)
Nun heisst es warten 8)
Vermute aber mal ganz stark, dass der zweite Eintrag dann verschwunden ist...
Aber fällt dann kurzzeitig gleich das ganze DNS aus?
Ist im Unbound was falsch konfiguriert?
Auf welcher Version bist du
Bei 20.7.x gab es meine ich Mal Unbound Probleme
-
Hast Du für WireGuard ein Interface unter Interfaces: Assignments angelegt? Wenn ja, evtl mal mit "Prevent interface removal" testen. Vielleicht klappt ja kurz die WireGuard Verbindung zusammen und das Interface verschwindet kurz. Damit dann vielleicht auch die Routen dahin...nur so ein Gedanke.
-
Auf welcher Version bist du
Bei 20.7.x gab es meine ich Mal Unbound Probleme
21.1.1 - die OPNsense wurde letzte Woche sauber mit 21.1 aufgesetzt...
Hast Du für WireGuard ein Interface unter Interfaces: Assignments angelegt? Wenn ja, evtl mal mit "Prevent interface removal" testen. Vielleicht klappt ja kurz die WireGuard Verbindung zusammen und das Interface verschwindet kurz. Damit dann vielleicht auch die Routen dahin...nur so ein Gedanke.
Angelegt ja, aber nur um den kompletten Traffic zu tunneln, wie hier beschrieben:
https://wiki.opnsense.org/manual/how-tos/wireguard-client.html#step-2c-assignments-and-routing
Interface ist auch nicht aktiv (sehe also keinen separaten Eintag unter Firewall/Rules) und vorm Löschen geschützt...
-
So, das Problem ist wieder da, seit wann weiss ich nicht, der Hänger war vermutlich nachts...
Der Eintrag unter "VPN: IPsec: Security Policy Database" ist noch vorhanden...
Sehr merkwürdig :o
-
Mittlerweile wird nicht mal mehr der IPsec-Tunnel aufgebaut, selbst nach Reboot der OPNsense...
€dit:
Nach Reboot der FritzBox steht der IPsec Tunnel wieder und der Traffic aus dem WireGuard geht auch erstmal wieder über den IPsec Tunnel - erstmal ;D