Entferntes Subnet (IPSec Site2Site) via WireGuard Roadwarrior erreichen

[opnboi]

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

[Gauss23]

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).

[opnboi]

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?

[Gauss23]

Genau

[opnboi]

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?

Code Select Expand

                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?

[opnboi]

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?

[opnboi]

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?

[opnboi]

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...

Code Select Expand


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]


[opnboi]

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:

Code Select Expand

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:

Code Select Expand

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

[opnboi]

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

[chemlud]

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.

[opnboi]

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?

[micneu]

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.

[opnboi]

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...

[micneu]

in deinem netzwerkplan habe ich nichts von einem vigor gelesen, irgend wie nennts du hier hardware die in deinem plan nicht eingezeichnet sind.