@eyetap said in DNS Forwarder bei Dual WAN im Failover:

Nun ja - logisch dass die Routen bleiben - OK. Nicht logisch wenn die auch, wenn das zugewiesene Gateway down ist, auch aktiv weiter versucht werden zu verwenden und dann Timeouts liefern.

Durchaus logisch, denn sie werden fest konfiguriert über DIESE GWs zu gehen. Wenn du keine GW Zuweisung machst, gehen sie übers Default. Das ist aber auch in der Doku beschrieben :)

@eyetap said in DNS Forwarder bei Dual WAN im Failover:

Einfach nur in der Annahme, dass der Provider bzw Downstream DNS flotter ist als ich. Wäre ja eigentlich auch traurig wenn nicht.. :)

Was ist Geschwindigkeit ggü Zuverlässigkeit? ;) Zumal der Vorteil beim echten Resolver nur einmal besteht, danach greift Caching und der Rest ist dann egal. Zu viel Zentralisierung war leider gerade bei DNS noch nie zielführend :)

@eyetap said in DNS Forwarder bei Dual WAN im Failover:

Mit genug Forwardern wär das ja kein Thema.. ;-)

Doch, denn die meisten bleiben dann doch wieder bei den großen/größten Forwardern hängen. Und dann gibt es schlicht Abhängigkeit von ein paar großen DNS Schleudern, die dann lustig fröhlich ausliefern können was sie wollen. Worin das gipfelt zeigt sich gerade erst beim Prozess gegen die (jetzt schweizer) Betreiber von 9.9.9.9 die per Verfügung dazu genötigt werden (sollen), dass diverse Domains nicht mehr erreichbar / auflösbar sind über ihre Resolver. Allerdings soll das dann auch nur aus dem entsprechenden Land nicht auflösbar sein, etc. bla fasel. Es ist wieder kompletter Nonsense, weil die Leute DNS nicht verstehen und die Komplexität von "IP Adresse ist keine fixe Hausnummer in Deutschland" nicht begreifen. Da klebt in den Köpfen, dass man IPs festnageln kann auf ein Land (jeder der schon GeoIP gemacht oder genutzt hat weiß wie ungenau und doof solch eine Annahme ist). Und dann ist das ja einfach zu machen. Dass die Umsetzung extrem schwierig und schwammig wird und im Endeffekt nur dazu führt, dass die Leute andere Forwarder - oder wesentlich sinniger - einen eigenen Resolver nutzen, der auf irgendwelche Forwarder pfeift und die Domain einfach vom eingetragenen SOA Server der Domain holt ist in den Kleinhirnen leider nicht angekommen.

Aber an genau diesen Prozessen sowie den vergangenen Problemen mit irgendwelchen Forwardern von Betreibern sowie Happenings wie DNS Search Redirection, falschen IPs statt NXDOMAIN Antworten, DNS Umleitungen, Domain Parking DNS Redirection und was-weiß-ich-nicht-mehr-alles-für-anderen-Schmutz lernt man auf die harte Tour, dass man von zentralen Ansätzen lieber die Finger lässt.

Die Idee, einfach lokal bspw. 10 oder noch mehr Forwarder einzutragen ist BTW leider genauso unsinnig, da die Forwarder/Logik das gar nicht sinnvoll nutzen kann. Der korrekte Ansatz in der Richtig wäre dann tatsächlich ein Konzept wie ODNS oder DoHoT was zusammen mit dnscrypt als stub resolver und DNS "loadbalancer" inkl. selection mechanism gegen DNS bias einhergeht.

Damit könnte man dann so halbwegs was anfangen :)

@shadeless said in DynDNS Client Einstellungen für STRATO:

Wenn du mehrmals innerhalb kurzer Zeit ein Update machst, sperrt dich Strato für ein paar Minuten bis wenige Stunden. Hab ich auch gehabt beim ausprobieren. Ging bis jetzt immer nach etwas abwarten von alleine wieder.

Ja, ging dann wieder :-)

@shadeless said in DynDNS Client Einstellungen für STRATO:

Anstatt "good %IP% | nochg %IP%" musst du "good %IP%|nochg %IP%" (ohne leerzeichen vor und nach dem |) eintragen.
Dann kann das Ergebnis richtig ausgewertet werden.

ok, habe ich drin. Werde es beobachten

@zomhad Der Kollege mit dem ich damals telefoniert hatte meinte, er mache gerade nix anderes, da sie gerade endlos Kunden von Kabelanbietern etc. bekommen würden und die natürlich pandemisch bedingt hauptsächlich ne stabile Verbindung brauchen würden und meistens eben in irgendwelche FirmenVPNs rein müssen. Und da hier ganz viel noch v4 only läuft und es durch MTU und sonstige Sperenzchen dann durchaus Probleme gab/gibt, wissen die da schon Bescheid. Solang sie noch größere IP4 Bereiche haben, wird das sehr wahrscheinlich kein Problem. Kabel- und Neuanbieter am Markt haben es da meist schwerer da sie auf nicht so große IP4 Segmente zurückgreifen können und schneller am Limit sind wo sie einsparen müssen.

@benjaminpc said in PfSense AWS OpenVPN kein Internet:

Wenn ich mich aber nun via OpenVPN verbinde kann ich zwar die PfSense pingen aber nicht die Server im LAN Netz
Ebenso haben die Server kein Internet

Beide Symptome könnten hier dieselbe Ursache haben, aber auch verschiedene.
Ich würde die Internet Verbindung der VMs als erstes in Angriff nehmen. Scheint mir leichter zu klären zu sein.

Nachdem die pfSense aus dem Internet erreichbar ist und ihrerseits die Server erreichen kann, besteht mal "physisch" eine durchgehende Verbindung.
Ich nehme an, vom LAN ist nach wie vor alles erlaubt, also die standardmäßige any-to-any Regel aktiv.

Dann versuche mal von einer VM einen Ping auf 8.8.8.8. Wenn das funktionieren sollte, liegt es vermutlich daran, dass die VMs keine Hostnamen auflösen können.

Falls der Ping auch scheitert, könnte das Outbound NAT nicht funktionieren. Dann würde ich die Frage stellen, wie dein WAN konfiguriert ist. Wenn manuell, hast du in den Interface Einstellungen auch das Gateway angegeben?

@jegr HAProxy 1.6 konnte noch kein HTTP/2, das wurde erst mit der Version 1.8 eingeführt. Die 1.6 Version war stable und die 1.8 devel.

Siehe https://www.haproxy.org/#desc

Ok, den Forward-Mode deaktiviert und dort die Host-Überschreibung gelöscht. Den Resolver-Mode wieder aktiviert und dort die Host-Überschreibung hinzugefügt.

In den Allgemeinen Einstellungen die beiden DNS-Server entfernt.

Mit dig vom Client aus die gw.meinedomain.de abegfragt. Als Ergebnis erhalte ich die LAN-IP.

So sollte es nun passen

@ileonard said in Hinter PfSense HaProxy KeyHelp:

Die Zertifikate müsste man ja wie gehabt in der Sense hinterlegen und dann noch einmal in KeyHelp.

Warum das denn? Wenn HAproxy die SSL Verbindung terminiert braucht der Server dahinter kein öffentlich gültiges Zert zu haben. Klar, ist schön, muss aber nicht. Müsste nicht mal SSL sprechen, denn das übernimmt gegenüber dem Client ja HAproxy für ihn - dafür ist er ja da.

Und ob das im Bild jetzt irgendwelche wurstigen Webserver 01/02/03 sind die am "HAproxy hängen" oder ob das irgendein ISP-haumichblau-machsdireinfach Server ist 😁 ist doch für HAproxy völlig egal. Ich weiß zwar nicht, wie in einem netz mit 192.168.4.x plötzlich eine 10.0.0.5 auftaucht (eigenes Netzsegment der pfSense dann?) aber für den HAProxy ist das einfach nur noch ein weiteres Backend das er bedient. Solang das richtig eingerichtet ist, ist dem der Server egal. Er braucht die Zerts zum Ausliefern und die Info, was er mit "kundendomain1, kundendomain2, wordpress3, etc." anfangen soll. Also per Host Header weiterreichen aufs Backend. Ende Gelände 😉

Aber dann sollte man sich vielleicht einfach überlegen, ob man - wenn man schon irgendein ISP Wartungsdings Server bauen möchte für Kunden - diesen dann nicht mit ner eigenen IP betreibt. Und dann eben notfalls noch ne zusätzliche IP oder nen Anschluß ranholt. "Mal eben" so nebenbei auf der kleinen Leitung noch nen Server zu hosten haben schon viele gedacht, die es dann zerlegt hat. Wenn das irgendein halbwegs ernstes Business werden soll, sollte man das von Anfang an auch so aufziehen und ernst nehmen und entsprechend bauen und nicht quick & dirty reinhauen. Das beißt einen später beim Wachsen wenns gut läuft nämlich ordentlich in den Allerwertesten.

Cheers

@fischershome said in Gast WLAN macht keine Namensauflösung....:

PFsense ist ein tolle Firewall aber vielleicht doch eine kleine Diva :-)

eigentlich nicht. Meistens (>99%) macht sie strichgenau das was man ihr sagt oder eben nicht sagt ;)

@fischershome said in Gast WLAN macht keine Namensauflösung....:

Sobald ich im DHCP die manuelle DNS Einträge entferne nimmt Pfsense nichts mehr vom Provider oder im Allgemeine Einstellungen die DNS Einträge. Beide Netze (Lan oder Gast-Wlan) machen die Probleme und bekommen nur eine DNS Server (IP-Adresse vom PFsense) vom DHCP und dieser reagiert nicht.

Ja natürlich macht sie das dann nicht - das SOLL sich ja auch nicht! Es wäre manchmal hilfreich, wenn man die Doku liest zu dem was man tut ;)
https://docs.netgate.com/pfsense/en/latest/services/dhcp/ipv4.html#servers

The DNS Servers may or may not need filled in, depending on the firewall configuration. If the built-in DNS Resolver or DNS Forwarder is used to handle DNS, leave these fields blank and pfSense® will automatically assign itself as the DNS server for client PCs. If the DNS forwarder is disabled and these fields are left blank, pfSense will pass on whichever DNS servers are defined under System > General Setup. To use custom DNS Servers instead of the automatic choices, fill in the IP addresses for up to four DNS servers here. In networks with Windows servers, especially those employing Active Directory, it is recommended to use those servers for client DNS. When using the DNS Resolver or DNS forwarder in combination with CARP, specify the CARP Virtual IP address on this interface here.

Also übersetzt: im DNS Server nichts eintragen führt zu:

DNS Resolver intern genutzt und konfiguriert: pfSense trägt sich selbst als DNS ein und schickt das an die Clients - was sie machen MUSS sonst ist der ganze pfBlocker DNSBL Kram nämlich für die Tonne Wenn DNS Forwarder aus ist und sonst nichts antworten würde, werden die System DNSe vom OS selbst (aus System / General) als DNS an die Clients weitergegeben damit sie überhaupt welche bekommen. Ansonsten fülle hier die Felder aus mit IPs die an die Clients weitergereicht werden sollen.

Wenn der Client bei einem IPconfig /all (Windows) anzeigt, dass der DHCP und DNS Server die pfSense IP auf dem entsprechenden Interface ist, ist das richtig aufgesetzt, wenn man auf der Sense mit DNS und DNSBL arbeitet.

Wenn DNS dann vom Client mit einem simplen NSlookup nicht geht (siehe Virago), dann klemmts am DNS Resolver und man muss sich die Config mal anschauen. Meistens hat dann jemand irgendwelche ACL Listen definiert, den Resolver auf irgendwelche Interfaces gebunden/konfiguriert etc. was nicht passt und daher gibt er dem Client dann keine Antwort.

Cheers :)

@pfsense-user2019 die netzwerkkarte kostet 27 Euro :) Ist ein alter Server :)

@viragomann
Ja, pfsense läuft in Version 2.5.2

Ich lass das mal auf benutzerdefiniert, damit läuft es stabil.

@fireodo Dankeschön.

Frage hier gepostet:
https://forum.netgate.com/topic/169500/snort-restarting-needed-if-ip-list-edited

@viragomann
okay werde ich tauschen, danke.

@towatai

Nachtrag:

Ich schmeiß den Kram gleich aus dem Fenster und werde zukünftig als Tischler arbeiten anstatt "irgendwas mit IT"... ich habe die Lösung falls nochmals jemand auf das Problem trifft:

In der Fritzbox unter TELEFONIE ---> Eigene Rufnummern ---> Anschlusseinstellungen darf KEINE Ortsvorwahl stehen. Diese wird ansonsten bei jedem ausgehenden Anruf vor die eigentliche Nummer gesetzt und dann gehts natürlich nicht. Schön, dass die Fritzbox aber genau den Eintrag nach dem hinzufügen der Rufnummer automatisch setzt

@jegr
Ich habe den Fehler gefunden ! Meine Fresse was ein Staatsakt. Beim Paketmitschnitt sind mir Pakete aufgefallen die zu groß waren für UDP.
Screenshot 2022-01-21 at 14-00-00 pfSense home arpa - Diagnose Paketmitschnitt.png
Das SIP Protokoll ist extrem empfindlich gegenüber Änderungen. Da die Datenpakete zu groß waren wurden diese in zwei Pakete aufgeteilt. Dadurch wurde die SIP Nachricht ungültig und auf der Gegenseite verworfen. Ich habe zuerst mit den MTU Werten der Schnittstellen gespielt. Das hatte aber nichts gebracht. Die stehen nun alle auf 1492. Erfolgreich war die Einstellung der MSS Werte der Schnittstellen auf 1299.
Der Wert soll für verschiedene Scenarien ein guter Mittelwert sein. Hauptsache es läuft erstmal. Feintuning kommt später.

@jegr Danke für den Hint mit der Netzwerk-Karte! :) das wäre auch noch eine Idee.

Ich bin nun auch einen Ticken schlauer geworden.
Wenn ich es jetzt richtig verstanden habe muss ich mein Network Setup so umbauen, dass ich ein BRIDGED Setup habe. Dann kann ich eine neue MAC Adresse für die zusätzliche "IPv4" setzen UND DANN kann ich erst diesem Adapter mit der zusätzlichen IPv6 auch das neue IPv6 Netzwerk im Hetzner-Robot zuweisen. (so zumindest der plan)
Routing scheint nur über MAC Adressen zu klappen.

Was meinst Du dazu?

Schöne Grüße
Ralph

@digitalcomposer said in Neustart von WireGuard per Cronjob:

ass Pfsense nicht checkt, dass die disconnected sind und will kein HandShake machen.

Bezweifle ich stark. Wireguard ist da sehr sensitiv. Wenn du keinen Input vom Client bekommst, sieht er das. Aber da am Cryptorouting nichts geändert wird, macht für mich da ein Neustart auch keinen wirklichen Sinn. Das hört sich eher nach Gegenseite an also die Thin Clients, ansonsten würden das ja alle Clients auf der pfSense haben und nicht nur die.

Zudem ist WG da eigentlich extrem gesprächig. Sobald der eine Verbindung aufbauen kann wird ers auch versuchen. Im "Client" Szenario wirds aber eher das Problem sein, dass der Server den Client eh nie erreichen kann weil hinter NAT, also MUSS der Client die Verbindung wieder reconnecten.

Eventuell irgendwo "verboten", dass sich die IPs ändern dürfen (Verbindung von dynamischen IPs aus nicht erlaubt)?

@woodsomeister said in Unbound Verhalten bei mehreren DNS Upstream Resolvern:

Wenn ich dich richtig verstehe, kann ich also quasi gar kein Regelwerk anlegen, wie Unbound Anfragen verschickt, weil Unbound anhand definierter Qualitätskriterien die Upstream DNS Resolver anfragt. Richtig?

Das sieht zumindest in den Upstream Dokus von Unbound so aus, ja. Laut diesen verhält sich Unbound wie beschrieben und es würde auf die Latenz ankommen, ob er einen Server nutzt oder nicht.

@saylles said in LXC und das Internet:
Er gab für mich nur erstmal kein Sinn weil ich verstehen könnte wenn es dann nur der Container ist der keine verbindung hat aber es sind alle Container die an dem Interface hängen.

Ach so. So hatte ich das gar nicht verstanden.
Dann wird das wohl auch nicht helfen.

@jegr
Ich habe gestern den ganzen Tag mit Port Freigaben und Weiterleitungen getestet ohne Erfolg. Zum Schluß habe ich nochmal die DNS Server per Hand in die Fritzboxen eingetragen. Das hat dann funktioniert. Der DNS Fehler war weg ! Das hatte ein Tag vorher nicht funktioniert. Deshalb bin ich dann hingegangen und habe die zusätzlichen Regeln Schrittweise deaktiviert und gelöscht. Am Ende waren alle neuen Regeln wieder raus bzw. auf dem alten Stand und es funktionierte immer noch. Kapiere ich nicht so ganz, aber gut ein Problem weniger.
Allerdings funktioniert die Telefonie noch nicht ansatzweise aber dafür mache ich mal ein neues Thema auf da das DNS Problem gelöst zu sein scheint.
Erstmal vielen Dank an alle die beim Suchen geholfen haben !

@jegr said in Problem mit dem Service pfBlockerNG:

Die alte 2er bin ich mir gerade nicht sicher ob das nicht immer alles lief.

Dass weiß ich auch nicht mehr - ist schon rel. lange seit ich auf devel umgestiegen bin ...