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

@JeGr genau so war es, denk ich zumindest.

Was war es denn oder ists noch immer kaputt? :)

Ich habe jetzt rumgetestet und herausgefunden, dass es an dem zweiten WAN-Anschluss liegt (LTE-Modem mit Telekom-Sim).
Über den ersten WAN-Anschluss von der Telekom klappt das Ganze (VDSL).

Hier will ich aber die Adresse des zweiten Anschlusses auflösen, was nun plötzlich nicht mehr möglich ist. Der Anschluss ist von T-Mobile und funktioniert mit dem dyndns-Account seit Jahren.
Nun plötzlich nicht mehr.
Da muss ich wohl die Telekom kontaktieren.

Daher ist der Beitrag als gelöst zu betrachten :-)

Gruß.

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

@tpf
Eine FW-Regel für den Zugriff auf die private IP hast du?
Die braucht es schon, denn das NAT geschieht vor der FW.

Vielen Dank an @JeGr für die Hinweise !!!

Die Telefonie funktioniert nur und das Hauptproblem hatte nichts mit der pfsense und deren Konfiguration zu tun.

Entscheidend war mein Nachtrag von gestern Abend, nämlich dass die Diagnostics -> States für die 192.168.0.4 ausschließlich Verbindungen zu 5060 anzeigten, aber keine zu den STUN- oder RTP-Portts.

Voreingestellt im C430A GO sind die RTP-Portts 5004 - 5020.

Bei 1&1-Verstate gibt es auch eine Konfigurationsanleitung für das C430A GO, in dem diese Prots so eingetragen sind wie von mir bis jetzt verwendet. Das 1&1-Hilfecenter schweigt sich zur RTP-Konfiguration gleich komplett aus.

Dennoch hat mich das RTP-Problem nicht losgelassen. Den entscheidenden Hinweis fand ich im Tutorial: 1und1 VoIP mit Fritz!Box HINTER opnSense aus dem OPNsense Forum
Dort findet sich prominent der Hinweis auf die von 1und1 genutzten RTP-Ports 5070 - 5079. Damit nun funktioniert die Telefonie einwandfrei.

Was bleibt ist ein extrem schaler Beigeschmack hinsichtlich des Supports von 1&1 und deren Tochtergesellschaften wie Drillisch. Man will die Privatkunden offenbar mit aller Macht zur Nutzung von FritzBoxen zwingen. Informationen zur korrekten Konfiguration sowohl von DSL- wie Glasfaser-Internet und der Konfiguration der 1&1 Telefonie-Verbindungen gibt es ausschließlich für Fritten. Auch telefonisch erhält man lediglich die Auskunft: "wir supporten NUR FritzBoxen". Für 4,99 Miete/Monat senden die einem aber gerne eine 7510 (Kaufpreis ab rund € 100) zu ...

@jogovogo said in FritzBox<->pfSense IPsec VPN:

Guten Abend zusammen!

Vielleicht wird dieses Thema ja noch beobachtet...

Wir hatten stabile VPN Tunnel am laufen haben die FRITZ!Box auf die Version 8.03 updated nun bauen sich diese leider nicht mehr auf.

An der Config hat sich selbsterklärend nichts geändert.
Es kommt folgende Meldung, IKE-Error 0x2026 "no proposal chosen.

Hört sich irgendwie nach Phase 2 an, ob sich da seitens Fritz OS irgendwas geändert hat? Ggf. hat ja einer ähnliche Erfahrung und kennt die aktuellen Chiffrewerte.

Cheers
Ron

Hi,

leider hast du dich an einen ganz anderen Thread drangehangen, darum ging die Frage auch komplett unter. Bitte tatsächliche Probleme/Support hier in den Forenteil packen und nicht ins Allgemeine Netzerkthemen Laber-Unterforum :)

Es kommt folgende Meldung, IKE-Error 0x2026 "no proposal chosen.

Am Einfachsten ist es da die pfSense auf der remote Seite im Log zu untersuchen, da wirst du auch das NO_PROP finden. Davor findet sich dann auch meistens ein IKE Austausch mit "Die Crypto bot mir die Fritte an", "die hab ich selbst" - "kein match".

Damit kann man eigentlich immer gut sehen, was tatsächlich übermittelt wurde egal was man bei AVM eingestellt hat und was man selbst konfiguriert hat. No Proposal heißt in dem Zusammenhang mit fast 100% Sicherheit, dass das Setting mit AES-SHA256-DHmode nicht mehr stimmt und die Fritte mit dem Update die Einstellungen resettet hat und ggf. einen anderen Hash, DH Modus oder ne andere Crypto gewählt hat. Was und welche genau siehst du aber nur auf der Sense im Log.

Am Besten bei sowas die Sense in Phase 1 auf "responder only" schalten, so dass die nur auf eingehende Requests antwortet und dann im Log die Strings vergleichen was ankommt und was die Sense anbietet - wird sicherlich nicht übereinstimmen weil AVM mal wieder Settings geändert hat :)

Cheers :)

@fms said in Default ipsec_get_keystate: no keystate:

@bon-go said in IPSec-Tunnel - received NO_PROPOSAL_CHOSEN error notify:

IKE log: 173835.242284 Default ipsec_get_keystate: no keystate in ISAKMP SA im Lancom trace

Hallo,

Kann mir jemand sagen, was no keystate bedeutet? Was bewirkt diesen Fehler? Ich finde dazu leider nichts im Web.

Danke und viele Grüße, fms

Hi,

das hat nichts mit pfSense zu tun und war in diesem alten Thread aus einem Capture(?) von einer Lancom Gegenstelle, darum wird dir hier kaum jemand dazu antworten können. Wenn du allerdings das Problem mit einer Sense als Gegenstelle hast, kannst du gern das IPsec Log der Sense dazu hier posten, dann können wir dem gern auf den Grund gehen, was der Fehler sagt.

Ich würde annehmen, dass es entweder schon beim Key Exchange scheitert (Phase 1, Passphrase oder Crypto Cipher) oder dass die Verbindung abgebrochen wurde und daher keine IKE Phase mehr besteht.

Cheers