@esquire1968-0 Puh, war jetzt mal davon ausgegangen, dass der Host bei dir in der Wihnung, der Firma steht. Viel kann man bei dem was das in deinem Bild zu sehen ist an virtueller Hardware auch nicht konfigurieren. 1 GB empfinde ich an RAM inzwischen aber als recht wenig. Konkrete Ideen habe ich da jetzt keine, außer mal mind. 2GB RAM zu testen. Meine virtualiesierte pfsense hat 6GB. Ich würde mich mal an den Support von Netcup wenden.

@Nico-Borsch Ist zwar Off-Toppic, aber du kannst alle LAN-Regeln unterhalb der IPv6 Default rule löschen, da diese eh niemals greifen, solange die Alles-erlauben-Regeln aktiv sind. ;-) Sieht so aus als würdest du ADS nutzen? Die Sense kennt somit die Domain-Clients nicht. Damit das funktioniert, musst du im DNS-Fowarder oder Resolver auf der Sense Domain-Overrides für deine ADS-Domain einstellen. xmodus.local 192.168.150.27 ADS DNS 1 150.168.192.in-addr.arpa 192.168.150.27 ADS DNS PTR 1 xmodus.local 192.168.150.28 ADS DNS 2 150.168.192.in-addr.arpa 192.168.150.28 ADS DNS PTR 2 Jeweils pro Server einen forward und einen reverse-lookup Eintrag. Dass deine Clients andere lokale Clients im Netzwerk auflösen können, liegt daran, dass sie nicht über die pfSense gehen.

Ich habs mittlerweile hinbekommen. Falls es jemandem hilft: Hier das config Snipped für telegraf.conf [[inputs.tail]] files = ["/var/log/filter.log"] from_beginning = false pipe = false watch_method = "inotify" # Data Format Configuration data_format = "grok" # Simple pattern that captures the syslog header and comma-separated filterlog data grok_patterns = [ #IPv4 "%{SYSLOGTIMESTAMP:timestamp} %{DATA:hostname} %{WORD:process}\\[%{INT:pid}\\]: %{INT:rule_number},%{DATA:sub_rule},%{DATA:anchor},%{DATA:tracking_id},%{DATA:interface},%{DATA:reason},%{DATA:action},%{DATA:direction},%{INT:ip_version},%{DATA:TOS},%{DATA:ECN},%{DATA:TTL},%{DATA:ID},%{DATA:offset},%{DATA:Flags},%{DATA:protocol_id},%{DATA:protocol},%{INT:length},%{DATA:source_ip},%{DATA:destination_ip},%{INT:source_port},%{INT:destination_port},%{INT:data_length}" , #IPv6 "%{SYSLOGTIMESTAMP:timestamp} %{DATA:hostname} %{WORD:process}\\[%{INT:pid}\\]: %{INT:rule_number},%{DATA:sub_rule},%{DATA:anchor},%{DATA:tracking_id},%{DATA:interface},%{DATA:reason},%{DATA:action},%{DATA:direction},%{INT:ip_version},%{DATA:class},%{DATA:flow_level},%{DATA:hop_limit},%{DATA:protocol_id},%{DATA:protocol},%{INT:length},%{DATA:source_ip},%{DATA:destination_ip},%{INT:source_port},%{INT:destination_port},%{INT:data_length}"] # Custom measurement name name_override = "pfsense_filterlog" # Static Tags [inputs.tail.tags] log_type = "pfsense_firewall" Hab noch nen Spalten-Dreher im IPv6 Pattern drinnen und das Grafana-Output muss ich noch etwas hübsch machen. Aber im Groben tuts was ich wollte. [image: 1750060313758-1e05e1f5-536c-490f-af9f-93d40c974229-image-resized.png]

@Wischi83 said in Problem mit Next Server Adress Weitergabe durch DHCP: @Wischi83 said in Problem mit Next Server Adress Weitergabe durch DHCP: 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 Das spricht nicht dagegen, dass es durchaus sein kann, dass die Info NICHT von der Sense kommt. Rogue DHCP sind ein Ding. Falsche Bootserver sind ein Ding. Switche, die L2-smart/L3 können und dazwischengrätschen sind ein Ding. Ich habe keine Ahnung was in deinem Setup alles involviert ist. Es muss nicht alles immer ein Firewall Problem sein. Und wenn noch dazu nicht einmal ein TCPdump zeigt, dass die Sense hier falsche Werte vergibt, tue ich mir sehr schwer, hier mit dem Finger auf die Sense zu zeigen und zu sagen "Ha! Genau, der DHCP/Kea macht da Mist!". Das klingt dann eher nach "irgendwas/wer merkt sich alte Werte". Und was und warum sind schwer zu debuggen. Aber es wäre ja einfach, mal den DHCP der Sense einfach komplett abzuschalten und dann das ganze nochmal durchzuspielen. Denn wenn dann immer noch falsch gebootet wird, wie soll dann die Firewall schuld sein? Cheers :)

@JeGr ich gebe Ihnen Recht, was die Einfachheit einer pfsense/OPNsense angeht, um "Regelsalat" zu verhindern. Und auch verstehe ich Ihren Einwand, das dadurch viele Support-Abfragen reinkommen können. Seinen Sie gewiss, ich habe lang genug Level 1 bis Level 3 Support gemacht. Es sollte sich grundsätzlich die Frage gestellt werden, für was benötige ich eine Firewall, und was sollte mir die Firewall liefern bzw. schützen. Und natürlich ist für mich eine Firewall keine Spielwiese, sondern ich weiß was für ein Regelwerk ich benötige und haben möchte, und was nicht. Gut das ich mit der Meinung von vorgefertigten Floating Rules bei pfsense/OPNsense nicht alleine stehe, und Foren genau mit dem Thema gut gefüllt sind. Zudem sollten man sich fragen, warum etablierte Firewalls wie Fortinet/Juniper, Check Points keine Standard Allow/Floating Rules haben (DENY ALL first), und explizite Management Ports. Zudem ist eine Standard Rule mit DNS/HTTP(s) schnell von LAN to WAN erstellt, und erzeugt kein "Regelwerksalat". Eine DENY ANY ANY Rule am Ende des Regelwerks, die zuerst LOGs erstellt, um zu sehen warum ein Client nicht funktioniert, und die dazu gehörigen Ports dann öffnet (wenn gewünscht), ein Standard Prozedere. Aber nochmals, ich gehe konform mit Ihnen, das es für den Home User, einfach wie möglich gemacht werden sollte, trotzdem sollte man für erfahrene User die Freiheit geben werden, eine pfsense/OPNsense selbst zu kontrollieren und zu managen. Auch ich sehe kein Problem, eine Abfrage beim Setup einzubringen, ob ich Standard allow floating Rules haben möchte oder nicht und dann eben nur die Management Ports Rule erstellt. Ich verstehe Ihre Support Sichtweise und wünsche Ihnen und Ihrem Team noch stressfreie Support-Tage.

@heiko3001 Stell das doch mal ins englische Forum hier. General pfSense Questions oder IPv6.

@heiko3001 said in Kein Zugriff auf Dienste trotz Portweiterleitung: @Bob-Dig Ich könnte dich knutschen, das ist die Lösung. Leider wurde es in 2.8 nicht gefixt, aber jetzt weiß ich Bescheid. Genial! Ich hatte so ein bisschen die Patches in Verdacht, aber explizit darauf wäre ich nicht gekommen. Wenn die State Policy das Problem ist gibt es aus irgendeinem Grund an einer Stelle asymmetrisches Routing, was ein Netzwerk-Designfehler ist. Das liegt nicht an "das ist kaputt", sondern meistens an einem Problem im Netz. Darum hat @viragomann da völlig recht, dass man dazu erstmal die Details zum Netz un den betreffenden Regeln bräuchte um das genau zu verstehen. Kaputt oder ein Fehler ist das aber nicht. Das Verhalten ist schon seit 24.03 in Plus drin und funktioniert dort genau wie es soll. Wenn es Probleme gibt, dann liegen die zu >90% an einem Problem beim Routing, nicht an "das neue Feature/Setting ist kaputt" :) Cheers

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

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

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.

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

@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 tracepath -4 www.google.com 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 ...