Messages

Habe es selber gelöst.
Mann muss in der WireGuard Config der Fritzbox die Interface Adresse weglassen.
Dann läuft der Traffic problemlos in beide Richtungen.

Code Select Expand

[Interface]
ListenPort = XXXXX
PrivateKey = XXXXX

[Peer]
PublicKey = XXXXX
AllowedIPs = 10.143.32.0/24, 192.168.188.0/24
PresharedKey = XXXXX
Endpoint = XXXXXX

Hallo,

ich würde gerne einen Standort über das Fritzbox Wireguard mit unserem VPN Gateway verbinden.
Zurzeit ist das mit einem Rapsberry Pi verbunden, wie auf dem ersten Bild. Das Konstrukt funktioniert Problemlos.

Wir möchten aber den Pi weghaben und das mit der Fritzbox verbinden, wie auf dem zweiten Bild. Auf blöd haben wir einfach die Pi WireGuard Config in die Fritzbox hochgeladen.
Das ganze verbindet sich auch. Die Verbindungen funktionieren aber nur in eine Richtung.

172.23.56.0/24) -> 192.168.188.0/24 funktioniert.
192.168.188.0/24) -> 172.23.56.0/24 funktioniert nicht.

Ich dachte das lag zuerst an den abgeschalteten statischen Routen in der Fritzbox die den Pi als Gateway für die Netze 10.143.32.10/24 und 192.168.188.0/24 angibt. Das weglöschen der Route löst das Problem aber nicht.

Kann es sein das die Fritzbox irgendwelche einschränkungen hat?

Fritzbox WireGuard Config

Code Select Expand

[Interface]
Address = 10.143.32.4/24
ListenPort = XXXXX
PrivateKey = XXXXX

[Peer]
PublicKey = XXXXX
AllowedIPs = 10.143.32.0/24, 192.168.188.0/24
PresharedKey = XXXXX
Endpoint = XXXXXX
Aktueller Aufbau
You cannot view this attachment.

Neuer Aufbau
You cannot view this attachment.



Gruß
SirNibo

Hallo,

meine OPNsense resettet sich seit den letzten 3 Tagen einmal täglich von alleine.
Ich sehe im log keinen shutdown Befehl. Wenn das passiert, dauert auch der DSL Connect sehr lange. Fast 10 Minuten.
Wenn ich sie normal reboote, nachdem sie einmal verbunden war, funktioniert der Reconnect auch problemlos.

Kann das Hitze sein oder läuft der RAM voll?

Es taucht nur irgendwann einfach ein Boot auf.

Code Select Expand

<13>1 2025-02-20T21:52:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="1"] <7>cannot forward from fe80::1eed:6fff:fe99:2305 to ff02::1 nxt 17 received on bge0
<13>1 2025-02-20T22:02:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="1"] <7>cannot forward from fe80::1eed:6fff:fe99:2305 to ff02::1 nxt 17 received on bge0
<13>1 2025-02-20T22:12:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="1"] <7>cannot forward from fe80::1eed:6fff:fe99:2305 to ff02::1 nxt 17 received on bge0
<13>1 2025-02-20T22:22:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="1"] <7>cannot forward from fe80::1eed:6fff:fe99:2305 to ff02::1 nxt 17 received on bge0
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="1"] ---<<BOOT>>---
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="2"] Copyright (c) 1992-2023 The FreeBSD Project.
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="3"] Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="4"]      The Regents of the University of California. All rights reserved.
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="5"] FreeBSD is a registered trademark of The FreeBSD Foundation.
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="6"] FreeBSD 14.2-RELEASE-p1 stable/25.1-n269632-cc316253c68 SMP amd64
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="7"] FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git llvmorg-18.1.6-0-g1118c2e05e67)
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="8"] VT(vga): resolution 640x480
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="9"] CPU: AMD Turion(tm) II Neo N54L Dual-Core Processor (2196.42-MHz K8-class CPU)
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="10"]   Origin="AuthenticAMD"  Id=0x100f63  Family=0x10  Model=0x6  Stepping=3
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="11"]   Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="12"]   Features2=0x802009<SSE3,MON,CX16,POPCNT>
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="13"]   AMD Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!>
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="14"]   AMD Features2=0x837ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT,NodeId>
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="15"]   SVM: NP,NRIP,NAsids=64
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="16"]   TSC: P-state invariant
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="17"] real memory  = 4294967296 (4096 MB)
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="18"] avail memory = 3975536640 (3791 MB)
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="19"] Event timer "LAPIC" quality 100
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="20"] ACPI APIC Table: <HP     ProLiant>
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="21"] FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="22"] FreeBSD/SMP: 1 package(s) x 2 core(s)
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="23"] random: unblocking device.
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="24"] Firmware Warning (ACPI): 32/64X length mismatch in FADT/Gpe0Block: 64/32 (20221020/tbfadt-748)
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="25"] ioapic0 <Version 2.1> irqs 0-23
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="26"] Launching APs: 1
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="27"] random: entropy device external interface
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="28"] wlan: mac acl policy registered
<13>1 2025-02-20T22:33:07+01:00 dtm1-fw1.nibo.rek kernel - - [meta sequenceId="29"] kbd1 at kbdmux0

Jemand eine Idee?

Gruß
SirNibo

Auch mein seit heute neu erworbener AP von Ubiquiti macht schon Probleme bis ich diesen Switch neustarte.

Moin,
ich verstehe das so das du nach 6h keinen Zugriff mehr auf das Internet hast!?
Aber von aussen (aus dem Internet) kommst du auf deine Server/Services?
Und die Verbindungen gehen auch über die OPNsense und nicht daran vorbei wegen eines Switches or what ever?
Ist schwer zu ersehen weil durch deine knappe beschreibung viel spielraum ist. Und da du VLAN nutz, die Fritte das nicht beherrscht, liegt es nahe das da ein Switch zwischen hängt.

Du kannst aber über die WAN Schnittstelle auf die Opnsense (nach 6h)? Nur das Routing nach aussen (Internet) geht nicht?

Probierst du nach einem Ausfall mit einem client oder auch mit einem zweiten?
Nutzt du DHCP?

Die WAN Karte ist an der Fritzbox dran. Das Netz zwischen Fritzbox und WAN Karte hat überhaupt keine Vlans. Die VLAN Sachen sind unterhalb der OPNsense.
Wenn das Problem auftritt, kann die OPNSense schon alleine nicht mehr über die WAN Karte kommunizieren. Sie erreicht auch nicht mehr das Netz der Fritzbox. Das auch nur über IPv4. In der Routing Tabelle wird weiterhin das Fritzbox Netz angezeigt und die Fritte selber als Gateway. V6 läuft weiterhin tadellos. Aber der umgekehrte Weg, von außen auf die WAN Karte funktioniert weiterhin über V4.
Ich hatte es schon mal beruflich, das ein TP Link Switch mal ein ganzes Vlan lahmgelegt hat. Auch Geräte die daran nicht  angeschlossen waren, liefen nicht mehr. Sie kamen auch nicht ins Internet. Da ich hier einen TP Link benutze, habe ich irgendwie ihn als Verdacht. Nachdem ich die OPNsense nochmal neu installierte, habe ich auch die Firmware der Switches aktualisiert. Jetzt habe ich seit Gestern 23 Uhr bis jetzt Ruhe.

Hi,
meine neu installierte OPNSense funktioniert nach einem halben Tag nicht mehr.
Über die WAN Schnittstelle geht nach ungefähr 6 Stunden nur noch Ipv6.
Zurzeit ist das noch ein Testsystem.
Fritzbox -> OPNsense -> Testnetz.
Die Opensense ist virtualisiert auf einem Unraid Server. Die WAN Karte direkt an die OPNSense durchgereicht.
Auf der LAN Karte sind 4 Netze, wovon 3 Stück als VLAN über den Host eingerichtet sind.
Ich habe die OPNSense jetzt 3 mal neu installiert. Es läuft am Anfang alles problemlos, irgendwann kommt man aber die WAN Karte nicht mehr raus. Kurioserweise funktioniert der Zugriff von außen nach ihnen weiterhin Problemlos. Auch alle Nat Ziele werden erreicht.

Hallo,

ich möchte ein Site-to-Site OpenVPN Struktur die aus Ubuntu 20 to Debian 10 besteht, gegen eine
OPNSense to Debian 10 umwandeln.

Ich finde immer nur Anleitungen, wie man eine Site-to-Peer Konfiguration zwischen OPNSense und Debian erstellt.
Muss auf der OPNSense Site-to-Site oder Site-to-Client konfiguriert werden?
Ist es möglich auch die vorhanden Zertifikate zu übernehmen oder muss man alles neu erstellen?

Gruß
SirNibo