@nowa-it Das gleiche Verhalten konnte ich auch so nachstellen. Die Einstellung TCPmssFix ist Standardmäßig aktiviert und scheint schon was damit zu tun zu haben. Nur leider wirkt sich das nur auf IPv4 aus und nicht auf IPv6. Dort wird das entweder ignoriert, oder ein falscher Wert wird ausgewürfelt.

@kira12 Das Problem dürfte da eher das fehlende/mangelnde Verständnis sein, von denjenigen, die diese vermeintlichen "HowTos" schreiben und propagieren. Das reicht von "works for me" über "sie wissen es nicht besser" bis zu "mir egal, ich mach das Video eh nur für Klicks" Howtos, daher ist es in der Masse eher schwierig zu wissen, ob etwas wirklich sinnvoll/gut ist oder nicht. Daher würde ich an der Stelle immer zuerst offizielle Quellen lesen und die neue Doku mit zusammengefügten Inhalten aus dem ehem. Buch und der off. Doku ist dahingehend wirklich gut und erklärt die Grundlagen auch für Themen wie Rule-Processing-Order und Co. Wenn man das im Kopf hat dazu, erklärt es sich von selbst ob/warum manche Regeln weiter oben stehen müssen als andere und warum es - wie in deinem Fall - überhaupt keinen Sinn machen kann. Wichtig sind lediglich drei Dinge, wenn du policy routing machst (also mit Regeln): Überlegen, WANN deine Regel zutrifft und ob es alle Fälle trifft, die du so routen möchtest (also ob du dir mit Regeln darüber oder darunter irgendwas abgräbst o.ä.) Das richtige Gateway setzen oder die entsprechende GatewayGruppe Daran denken, dass ein erzwungenes Gateway in einer Regel auch Verkehr DORT hinschickt, der ansonsten mit Gateway * woanders hin laufen würde! Beispiel für #3: Du hast ein 4-er Konstrukt. WAN, WAN2, DMZ, LAN. Auf dem LAN legst du nun eine Regel an, dass nicht wie bisher any any via * sondern any any via Failover_Gateway_xy geroutet wird. Damit willst du automatisch von WAN auf WAN2 und zurück schwenken wenn WAN mal kaputt gehen sollte. Wenn du sonst aber keine anderen Regeln hast, kommst du jetzt nicht mehr auf deine DMZ Hosts. Warum? Weil vorher mit * alles über die Routing Table geroutet wurde - und da steht natürlich drin: DMZ ist ein lokales Netz, da route ich direkt hin! Jetzt wird alles über WAN oder WAN2 gezwungen. Auch Sachen AN die DMZ die eigentlich lokal wäre. Wie gehts besser? Entweder man legt generell als sein Default Gateway jetzt nicht mehr WAN oder WAN2 fest sondern direkt eine Failover Gruppe (geht NUR mit Failover! Gruppen, KEINE Loadbalancing Gruppen!). Dann muss man an den Regeln NICHTS ändern, denn "*" steht dann automatisch für "default" und default ist ja WAN bzw. WAN2 je nach Failover Status. Das ist recht neu seit 2.4 und deshalb sprechen viele alte Howtos noch überhaupt nicht davon, dass das heute auch ohne Regeln geht! Alternativ mit PBR also via Regeln: Man erstellt einfach eine Regel mit Source LANnet und Dest DMZnet (oder einem beliebigen lokalen Alias), das dann wie bisher Traffic einfach mit Gateway * erlaubt. Alles was dann "ins Internet" gehen soll bekommt dann mit einer LANnet to any Regel das Failover oder Loadbalancer Gateway zugewiesen. Alleine daraus sieht man schon, dass die Howtos mit "Failover Regel ganz nach oben" kompletter Unfug sind, denn praktisch muss diese eher Richtung unten positioniert werden, wenn vorher noch anderer Traffic über bspw. VPNs, interne Netze, VLANs, IPSEC/OVPN Tunnel etc. geroutet werden soll. Daher: lieber informieren oder hier fragen bevor man fragwürdigen 08/15 Howtos folgt, die jemand einfach zusammengeklickt hat. @kira12 said in MultiWan LoadBalancing und Failover: z.B. https://forum.netgate.com/topic/58507/multi-wan-dual-and-policy-based-routing-with-failover/3 Alleine was man in dem Thread nachfolgend von bspw. phil liest, ist nochmal genau das was ich beschrieben habe. Die 3 Regeln, die im ersten Topic beschrieben werden einfach blind anzulegen bringt überhaupt nichts bzw. nur etwas, wenn man bisher lediglich vom LAN eine allow any Regel hatte und sonst nichts. Oder auch: a) You only want 1 rule for each from/to set of addresses - the system will use the first rule it matches, later rules will therefore not be matched/used. b) The more specific rules must be first in the list, then the specific traffic gets matched and the "other general crud" falls through to match the later general rule. Man braucht keine 3 Regeln, sondern man wählt für jede Regel aus, ob man diese über ein spezifisches Gateway (LB, Failover, default) schickt oder nicht. Und wie in b) beschrieben, spezifischere Regel bzw. enger gefasste Regeln müssen natürlich on top stehen, sonst würden sie bei einer any any Regel nie abgearbeitet werden. Ansonsten passiert das, was er in https://forum.netgate.com/post/407576 beschreibt. Die Regeln werden gar nicht erst abgearbeitet. Und zu guter Letzt ist der Beitrag von 2017 und damit lange vor der neuen Default Gateway Switching Methode entstanden. Heute würde das hier problemlos funktionieren OHNE irgendwelche Regeln zu verändern: [image: 1608202126861-failovergw.gif] Einfach ein FO-Gateway anlegen (Tier1 WAN1, Tier2 WAN2 bspw.), dieses als Default Gateway hinterlegen, speichern, fertig. Damit gilt für alle Interfaces und Regeln mit Gateway * automatisch ein Failover 1->2. Ohne Anpassung irgendwelcher Regeln. Wenn man das dann zusätzlich übersteuern möchte um ggf. bestimmten Traffic NUR über 1 oder 2 rauszuschicken oder manchen Traffic dann "Loadbalancen" möchte, kann man das problemlos machen. Cheers \Jens

Hi, deine Hardware scheint mir massiv überdimensioniert. Wenn du das in Betrieb hast wird deine CPU mit 1% Last vor sich herum dümpelt. Wenn du einen anderen Rechner dafür gewinnen kannst wird sich deine Stromrechnung darüber freuen... Gruß ré

Ich würde hier mal klar Schiff machen. Sauberes Netzkonzept, pro Standort welches auch ein paar Netze enthält für VLANs. Dann sauber das VPN (egal auf welcher Bais der Tunnel basieet) mit Routing aufbauen. Dann brauchst du kein NAT was bei SIP mit oder ohne ALG immer in einem Haufen sch... endet. Ne Sense kann im SIP rum wählen, ne Fritz ist dafür stumpf zu doof. Daher hat es vermutlich die ganze Zeit mit den Gurken funktioniert. Aber im Moment machst du Betrieb durch Zufall!

Certbot oder jeder andere Letsencrypt Client macht mit Domains im "HTTP-1" Modus gar nichts. Er sendet lediglich deinen Ausstellungs-Wunsch zu LetsEncrypt und deren Server greifen via Domainaufruf und HTTP (kein S!) auf die Domain zu, versuchen den .well-known Pfad abzurufen und damit die Domain zu validieren. Done. Mit Cloudflare als DNS für die eigene Domain geht das nochmal um einige Ecken leichter, weil man statt HTTP die DNS-1 Methode nutzen kann, wenn man die entsprechenden Daten wie API Key, Domain etc. hinterlegt. Dann wird ein TXT Eintrag in der entsprechenden Domain erzeugt (meinedomain.xyz) für den Hostnamen der validiert werden soll, LetsEncrypt testet den DNS (wieder von außen, dein lokaler DNS auf der pfSense ist da völlig irrelevant) und stellt je nachdem ob das klappt das Zert aus oder nicht. Ebenfalls Done. Beide Varianten haben nichts(!) mit deinem lokalen DNS und dem Überschreiben mit Host oder Domain Overrides in deiner pfSense zu tun. Der Host oder Domain Override - je nachdem was du brauchst/nutzt - sind lediglich dafür zuständig, dass deine Clients/Server nicht jedes Mal erst auf die externe IP auflösen, auf deiner pfSense rauskommen, da ggf. (wenn aktiviert) via NAT Redirection dann wieder zum Server zurückgespielt werden und insgesamt eben einmal mit dem Paket um den Block fahren, statt direkt ins Haus nebenan zu gehen, zu klingeln und reinzulaufen. Bildlich gesprochen :) Cheers \jens

@NOCling @the-other , das mit dem VLAN ist ne gut Idee, ich muss mir erstmal den switsch anschauen. (Ist ein kleiner HP 8 Port Gigabit switch) Werde mir das auf die todo Liste setzten wenn ich mal wider vor Ort bin. Wen der VLANs kann werde ich mich ggf. wegen der Konfiguration nochmal melden. Gruß Peter

ja das ist der plan. beim import wird der alte (bestehende) alias überschrieben (zuerst gelöscht dann der neue geschrieben) jetzt gerade dabei das xml file zu mergen und anschl. zu importieren. NP (edit) working .... xml edit und merge inkl restore ... funktioniert ohne reboot .. obwohl er anmerkt ein reboot may be needed so 1 down 43 to go [solved] NP

@viragomann So ja. :)

@wkn ganz einfach: Ich möchte meinen internen LAN Traffic über meinen performanten L3-Switch geroutet haben und nicht alles über meine virtuelle pfSense. Somit ist die pfSense kein Bottleneck.

@bob-dig said in Hilfe benötigt bei IPv6 Config WAN/LAN Unitymedia - test-ipv6 klappt nur sporadisch: @jegr Also wohl manuell auf den einzelnen Hosts... danke. Täte es lieber alles im Router machen. Wenns keine Server sind muss man im Normalfall gar nichts mehr irgendwo machen - dank SLAAC. Und Server konfiguriert man bei der Installation einmal durch - da ists mir egal ob statisch, semi-statisch via DHCP o.ä. - ich muss ja eh dran.

@jma791187 said in nächstes Treffen ?: bei mir im Kalender steht es auch drin. Aber das war beim ersten Treffen auch so :-( Ich muss also nur noch mal raussuchen, wie ich denn überhaupt teilnehmen kann. Sch... Kurzzeitgedächtnis Einfach ins Forum schauen: https://forum.netgate.com/category/81/pfsense-german-user-group Eintrag für den 2. Termin schon angelegt.

@jegr weil der default wert bei uns 155.555.555 Byte is ! weil kein vernünftiger ITler das so machen würd... wenn die Kunden selbst auf der Box spielen muss man ein paar HoneyPots einbauen

@tpf OK jetzt wirds klarer, ich dachte mit "Login" da kommt ggf. die Firewall UI also falsches Backend o.ä. Da ich in den allermeisten Fällen als Reverse Proxy/LB HAproxy einsetze, weil mir da Squid zu umständlich zu ist, kann ich da leider nichts zu sagen, an welcher Stelle der rumbuggt. Hab auch momentan leider viel zu wenig Zeit zum Basteln.

WiFi etc siehe @NOCling - dann hast du wirklich andere Probleme und sie sollte auch ihr Smartphone o.ä. schnell in Alu einwickeln :) - und die Mikrowelle wegwerfen. Bei Gigabit wirds wahrscheinlich mit der SG-2100 eng, das wäre dann eher was für die SG-3100 und drüber. Aber bei so großen Datenraten wird das Endgerät eben leider irgendwann teuer. Auch die neuen Fritten mit ihrem komischen 2,5Gbps Port für Gigabit Kabel/DSL sind ja nicht gerade Billigheimer, da ist man auch recht schnell bei über 250€ - und dann sind die Kisten nicht mal wirklich gut. Auf der anderen Seite rechnet sich so eine Hardware wenn sie ausreichend dimensioniert ist auch. Meine alte 7525 die bald abgelöst wird, lief jetzt etliche Jahre hier mit 200-400Mbps. Da hätte theoretisch auch ne kleinere Kiste gereicht aber nicht nur die Netzwerkports auch die Performance war eben immer top. Und wenn man den Betrag dann auf 3,4,5 Jahre sieht - ist das schon recht wenig.

@wkn said in Telekom FTTH PPPoE Einwahl mit SG-1100: @fireodo Ich weiss das das nicht automatisch geht, aber der OP muss es ja manuell gemacht haben und da das richtige Interface zugewiesen haben. Davon bin ich zwar ausgegangen - aber man weiß ja nie ...

Ich stimme da Rico zu. Evtl. macht das der VPN Provider absichtlich. Mit dem Provider darüber zu reden, würde kein Sinn machen. Wechsele einfach zu einem Provider, der unterschiedliche virtuelle IPs anbietet.

@sueimweb said in PfSense lässt Client nicht ins Internet trotz offener Firewall: ok, es war wirklich ein ganz doofer Fehler. Die machen wir doch alle Tja, beim Copy and Paste der Mac Adresse war ich in der Zeile verrutscht und hatte eine falsche Mac Adresse dort hinterlegt. Aber genau diese Art Fehler vergisst man viel zu häufig und sucht sich dann zu Tode bis man vielleicht mal drauf gestoßen wird! Mir selbst auch schon an anderer Stelle passiert, daher: lieben Dank dass du uns teilhaben lässt und ggf. nochmal anstößt, nachzuschauen ob da sich nicht doch irgendwo ein CopyPasta Fehler eingeschlichen hat Außerdem hätte ich den Post ungern gelöscht gesehen, wo hier so schön vorgelegt und debuggt wurde mit Packet Captures und Beschreibung - sowas muss auch mal gelobt werden!

@nonick said in WAN_DHCP6 zeigt andere Adresse als meine Fritzbox 6660: Dein WAN Interface ist auf DHCPv6 gestellt, bekommt aber keine Globale IPv6 Adresse vom Provider zugewiesen. Das deutet auf ein Konfigurationsproblem z.B. am WAN Interface hin Nicht zwangsläufig, die FB gibt bspw. gern das FE80:: prefix als Gateway raus, weil es IMMER funktioniert auch im Falle eines connection downs. Ist dort BTW konfigurabel, dass man wählen kann ob man link local bevorzugt möchte. Macht dort aber auch Sinn da sich die Prefixe ändern, wäre es Unsinn für unterbrechungsfreien Betrieb eine public IP6 zu nutzen, die dann ungültig wird und geändert werden muss. Die Default Route will man ja nicht ändern müssen. @nonick said in WAN_DHCP6 zeigt andere Adresse als meine Fritzbox 6660: sollte bei DHCPv6 klar sein. Aye, DHCP heißt eben dynamisch, da nimmt man was man bekommt ;) @dogfight76 said in WAN_DHCP6 zeigt andere Adresse als meine Fritzbox 6660: WAN_DHCP6 Pending Pending Pending Unknown Die Frage ist eher: funktioniert IP6 trotzdem oder nicht. Es kann auch lediglich ein Anzeige/Routing Problem von dpinger sein. Einfach Gateway mal kurz editieren und ohne Änderung speichern und schauen ob er es dann plötzlich pingen kann. Problem könnte deine Monitor IP6 sein. Die würde ich mal testweise raus nehmen.

Hi, ich glaube ich bin einen Schritt weiter. Es war ein Sperrfilter installiert und deshalb war "nur" DOCSIS 3.0. [image: 1606408898547-sperrfilter.jpg] Sperrfilter raus, Fritzbox neugestartet und jetzt sthet das unter "Kanäle" [image: 1606408883018-kan%C3%A4le1.jpg] [image: 1606408883022-kan%C3%A4le2.jpg] [image: 1606408883019-kan%C3%A4le3.jpg] So besser ? Speedtest mit VPN zeigt jetzt: [image: 1606409119061-tempo.jpg]

Im Grunde muss man gar nichts machen. In der Standartkonfiguration funktioniert VoWIFI reibungslos. Wichtig bei einem Vodafone-Tarif ist dass der DNS Server vom Provider oder eines deutschen DNS-Dienstes genutzt wird. Sonst klappt das nicht. Hintergrund ist das Vodafone damit überprüft, ob man sich in Deutschland aufhält. Da VoWIFI im Ausland von Vodafone nicht angeboten wird. Das hängt wo mit dem Roaming zusammen und damit das hier der Kunde nicht kostengünstig übers Internet telefonieren soll. https://de.wikipedia.org/wiki/Generic_Access_Network