Hi,
und vielen Dank für die Hilfe.
Ich habe jeweils die erste pingbare Adresse als Monitor-IP genommen.
Nun scheint es zu funktionieren.
Gruß orcape

@JeGr said in Dual Stack IPv6 an der pfSense - Interface verliert Verbindung:

Da du die v6 komplett geblurred hast nur eine Vermutung, aber das sieht so aus als hättest du vom WAN einen neuen v6 Prefix bekommen und der konnte irgendwie nicht sauber an die anderen Interfaces verteilt werden. Ich kann mich dunkel an ein Skript erinnern, das irgendwo rumgaukelt, was als Cron lief und nachschaute ob sich das v6 prefix geändert hat und wenn ja das WAN kurz durchtriggert, damit der Request für Prefix Delegation nochmal rausgeschickt wird. Aber das sollte nicht alle paar Minuten passieren.

Was ist denn überhaupt die pfSense Version? Da waren ja wenig Infos im Beitrag?

Cheers

Hast du zufällig dieses Skript noch irgendwo, ich vermute, dass ich davon betroffen bin. Danke im Voraus.

Feedback nach fast 24h.

Es hat geholfen und ich habe keine Crashreports mehr und eine DNS Registrierung benötige ich nicht, daher top zufrieden nun mit 2.8.0.

Grüße

@heiko3001 said in Kein Zugriff auf Dienste trotz Portweiterleitung:

Das hat bisher gut funktioniert und funktioniert auch weiterhin. Ich kann über die Firewallregeln auch super einstellen, welche Gerät über welches Gateway rausgehen.

Das bezweifle ich nicht. Dein Problem ist, wie ich es verstanden habe, eingehender Traffic, nicht ausgehender. Und dafür wären die Regeln interessant, nicht die Gateways.

Hallo Bob.Dig,

danke für die Antwort. Ich gehe leider auch entsprechend davon aus, dass es mit den Einstellungen nicht möglich ist.

Zu deiner Lösung mit dem DNS Forwarder muss ich mal testen ob der DNS Forwarder dann alle DNS-Features unterstützt / weiterreicht, die für den SIP-Trunk benötigt werden. Lieber wäre mir eine unmittelbare DNS Auflösung der (unterstützen) Endgeräte wie die TK-Anlage:

https://hilfe.companyflex.de/de/grundlagen/systemvoraussetzungen

Ich dachte vielleicht kennt jemand einen "Trick" wie ich z.B. für ein Subnet z.B. eine Variable von DNS-Server per DHCP vergeben könnte, bei der die Variable zuvor von den PPPoe DNS-Servern ausgelesen / bestimmt wird, o.ä.

@paolo256

Das ist richtig, das VLAN-Tagging kann entweder im Modem oder in der pfSense gemacht werden, nur halt nicht in beiden gleichzeitig.

Ich mache es in der pfSense, so kann man das Modem einfach tauschen, auch wenn das neue Modem kein VLAN-Tagging beherrscht. Glasfasermodem z.B..

@JeGr said in Problem mit Next Server Adress Weitergabe durch DHCP:

@Wischi83 said in Problem mit Next Server Adress Weitergabe durch DHCP:

Wenn Du Next-Server manuell auf .1.32 setzt und dann bootest (autoboot oder ähnlich, ohne reconfig des Netzwerk-Interfaces) kann .1.9 nicht von pfSense kommen. Die werden nur bei der DHCP Anfrage geschickt.

Das. Wenn manuell 32 geschickt wird und trotzdem auf 9 gebootet wird, kommt das nicht von der Sense. Dann sucht man sich da zu Tode, weil es nicht der Grund ist :)

Cheers

Dagegen spricht

@Wischi83 said in Problem mit Next Server Adress Weitergabe durch DHCP:

@JeGr gegen die Theorie stimmt ja das eine Hardware Maschine ebenfalls den 1.9 anfrägt.

Ich werd deine Ideen aber selbstverständlich bei Zeit durchspielen.

Wir drehn uns im Kreis, das führt alles zu nix. Ich werd die pfsense bei Zeit neu aufsetzen, bzw das nächste Update abwarten, eventuell wird das Problem durch eine der beiden Massnahmen gefixt

Um das abzuschließen. Auf der pfsense war noch 2.7.0 drauf.
Egal, was ich versucht habe, ich habs nicht mehr zum Laufen bekommen. Auch Reboot half nicht.
Auch andere Dyndns-Dienste kamen über LTE nicht raus (DuckDNS z.B.).

Nach Update auf 2.7.2 hat es sofort wieder funktioniert.
Nun funktionieren alle testweise eingerichteten DynDNS-Dienste tadellos...

Gruß. Arti.

@dogfight76 said in Nach Stromausfall keine Verbindung mehr zur pfSense und dadurch keine Internet:

Wie stosse ich das Update manuell an ?

Welche Optionen siehst du denn unter System -> Update -> System Update und unter System -> Update -> Update Settings? Dort solltest du den verwendeten Branch auswählen können.

@patient0 Danke Dir.

Jetzt wird mir die Betaversion auch nicht mehr angezeigt. So wollte ich das haben.

@JeGr
Da geb ich dir recht. Aber als sie noch "normal" im Kasten stand war es fühlbar deutlich wärmer. Hab da leider keine FLIR Aufnahme gemacht.

@Nico-Borsch said in OPEN VPN Tunnel kein DNS:

2025-05-07 18_00_59-Eingabeaufforderung.png

Ja das ist das Ergebnis

Das habe ich alles schon getestet. Ich habe es auch mit dem tool nmap überprüft.

Dann frage den DNS doch mal bitte was anderes und schau ob er das auflöst oder ob überhaupt kein Query durchgeht.

Zudem sind "Hostname" Anfragen immer flaky und nicht gut. Windows hängt nach eigenem Gutdünken da als Suffix mal ne Domain an, mal nicht. Das hängt SEHR vom Client und der Client Config bzw. dem ab was gepusht wird, aber auch ob der Windows Client bei der Einwahl Rechte hat DNS zu setzen etc. etc.

Darum arbeitet man weder mit "xy.local" Domains, da .local nicht für Lokalen Gebrauch gemacht wurde (da läuft automagic mDNS und Apple Magic Kram drüber) und sich komisch verhalten kann. Wenn man schon damit geschlagen ist und es nicht ändern kann aktuell, dann muss sichergestellt werden, dass die auch gepusht wird und auch definitiv am Client dann verwendet wird. Das ist dann bei Windows aber tricky. Darum nimmt man keine "Kurznamen" wie "hostname" sondern arbeitet mit FQDN, also "hostname.xy.local" was der DNS auflösen sollte.

Ich würde also mal testen, ob es nur ein Problem ist, weil Windows DNS mal wieder rumspinnt bei Hostname only oder ob auch die volle URI nicht aufgelöst wird. Also bitte mal mit hostname.xy.local oder servername.xy.local testen, denn der Server sollte seinen eigenen Namen ja wenigstens kennen. Wenn da auch "request timeouts" kommen, dann muss es entweder ne Regel sein - sieht nicht so aus weil allow any - oder die Windows DNSe / DCs haben die Firewall an und blocken das OpenVPN Subnetz weil sie es NICHT KENNEN. Darum macht man bei ordentlicher Firewall davor die Windows Firewall meist aus oder fügt Ausnahmen für die vorhandenen Netze dazu.
Windows Firewall auf Servern hat immer nur das eigene IP Netz als erlaubt drin, von anderen Netzen aus wird meist geblockt. Da das VPN Netz den Windows Kisten fremd ist, kann es schlicht sein, dass deren Firewall alles weghobelt.

Cheers

@JeGr said in Verständnisfrage MTU/MSS im GIF-Interface / AFTR:

Es liest sich eher so als wären ggf 1280 angezeigt worden aber nicht gesetzt gewesen

Die tatsächlich gesetzte MTU habe ich mittels

geprüft. Der mit tracepath verifizierte Wert entspricht der Anzeige in Status -> Interfaces für das gif0. Lasse ich die Felder für MTU und MSS leer ist der Wert 1280.

Für PPPoE-Verbindungen wird ja eine MTU 1492 empfohlen. Ich habe diese MTU 1492 nun auch für gif0 eingestellt, denn das ist ja da Defalt-Gateway für IPv4-Verbindungen. Als MSS verwende ich nun 1452. Damit läuft alles. Auch gmx.net oder web.de.