Ist das bei Dir wie bei Beerman? Nur mit abgeschalteten IGMP-snooping läuft das Bild durch Da mußte ja das IGMP-Snooping des Switch irgendeinen Einfluß auf die Unterbrechungen haben: Da der Multicast-Traffic nicht im Switch, sondern schon in der pfSense unterbrochen war (siehe weiter oben im thread), war meine Vermutung, daß Teile des IGMP-Traffic (Antworten des Media Receiver auf membership queries o.ä.) vom Switch verschusselt werden. Daher war der Vorschlag zuletzt den IGMP-Traffic aufzuzeichnen. Damit hätte man das erhärten können. Wenn das IGMP-Snooping problematisch ist, dann kann man darauf verzichten, wenn man hilfsweise den Multicast-Traffic für das IPTV in ein eigenes VLAN legt. Bleibt auch bei Dir bei einer Unterbrechung des Empfangs der IPTV-Traffic schon in der pfSense aus? Das sieht man ganz einfach im Traffic Graph auf dem Dashboard.

Hehe, ich sehe mein Problem auch nicht (klar) ;) Also: LAN: 192.168.2.0/24 DMZ: 192.168.3.0/24 RW: 192.168.9.0/2 (ipsec mobile, hier sind in den PH2 Definitionen die Subnets des VPNs eingetragen, das funktioniert soweit … ich sehe entsprechende Zugriffe in den pass Rules) Site 2 Site VPN: Mapped auf local 192.168.8.1 ipsec, ich kann hier an den Gegenstellen nicht viel ändern da vorgegeben Über das VPN (es werden später mehrere Site2Site VPNs werden) werden mehrere Subnetze gerouted über mehrfache PH2 Definitionen wie z.B: Mode: tunnel Local Subnet: LAN Local Subnet NAT/BINAT: 192.168.8.1 Remote Subnet x.x.x.x/24 In der Config ist das VPN übers LAN erreichbar, nicht jedoch über DMZ und Roadwarrior (entsprechende Rules sind dort drinnen) Wenn ich beim Local Subnet statt LAN DMZ nehme dann ist das VPN über die DMZ erreichbar, ich kann aber nicht über DMZ Rules z.B. nur einzelnen DMZ Hosts Zugang ins VPN gewähren, geht alles anden Rules vorbei durch. Dann ist das VPN nicht mehr über LAN oder Roadwarrior erreichbar... Deswegen meine Grundidee beim VPN ähnlich wie bei ipsec Mobile als Local Subnet ein eigenes Subnet ala 192.168.7.0 zu definieren ... wie und obs was bringt hab ich noch nicht rausgefunden P.S. Derzeit sind die Site2Site VPNs über einen OpenVPN Tunnel und 2 weitere Router an unserem alten Lancom VPN Router angebunden, die Roadwarrior können drauf zugreifen, das LAN und auch die DMZ. Ich versuche jetzt einfach den Lancom und den OpenVPN Tunnel wegzurationalisieren (anderer Standort) und die Site2Sites direkt an die pfsense anzubinden

So hab nun dich einige posts zu dem Thema gefunden….. Das Problem lässt sich soweit eingrenzen INFO: ISAKMP-SA expired Somit wird die entsprechende SA gedropped und die Verbindung aufgelöst. Die Frage ist nur ... warum? Die Parameter sind auf beiden Seiten identisch (ttls der keys usw). Auch die Tipps mit "Nat-N disable, DPD off oder Policy Generation auf unique) bringen keine Änderung..... Und ....  nach einem restart von racoon sind alle vpns per default offline

Nein, DoD ist für Einwählverbindungen, die an einem Zeit- oder Volumenanschluß genutzt werden. Heute bspw. UMTS Links. Hier wird die Verbindung nur aufgebaut, wenn tatsächlich Traffic nach extern geroutet werden soll. Ist das Interface down, wird auch kein Traffic durch bspw. DNS Anfragen oder Pings an das Gateway verschwendet (sofern es andere DNSe gibt die antworten bspw.). Somit kann man hier einen über Zeit oder Volumen abgerechneten Zugang einschränken, damit dessen Verbindung nicht versehentlich mitgenutzt wird oder unnötiger Traffic anfällt. (Deshalb nicht bei Bedarf herstellen, sondern nur bei Bedarf - hier liegt der Witz im Detail ;) )

TTL ist notwendig für den Eintrag den du via pfSense DDNS Client setzen lässt. Wenn du also bspw. up0.dyn.domain.tld setzen lässt, wird beim TTL von 300 bspw. die IP für 5min gecached. Kleiner als 5min wird bei den meisten DynDNS Anbietern selten angeboten und reicht m.E. nach auch aus. Man kann aber bspw. auch 180 für 3min machen. Die Frage ist da eher, was dein Provider zulässt als Minimum, da seine Server für diese Adresse dann ziemlich oft gefragt werden (kleines TTL heißt auch dass ggf. nach der Zeit die Anfragen direkt wieder an den Primary DNS durchschlagen) Öhm… bietet dir dein Provider wirklich(!) Dynamic DNS nach RFC2136 an oder willst du dir das selbst irgendwie hinfrickeln? Hier brauchst du nämlich DNSSec Daten, die auf dem DNS Server des Hosters entsprechend vorliegen müssen (du musst die dynamische DNS Zone - bspw. dyn.domain.tld - mit User/Key absichern und mit diesen Daten meldet sich dann der DNS Client beim DNS Server des Providers an). Wenn du keine Ahnung hast, was du dort eintragen musst, bezweifle ich, dass der Hoster das anbietet, denn sonst hätte der die Informationen mitgeben müssen. (Meistens ist es Key Type "Host" für einen direkten Eintrag wie oben - up0.dyn.domain.tld - und als Key Name wird ein sprechender Name vergeben und dann ein HMAC MD5 Key für das Key Feld) UDP (prot). Use Public IP ist nur für dich relevant, da es beeinflussen kann, was die pfSense dann als IP in den DynDNS Record reinschreibt. Da hatte ich zu ein Ticket aufgemacht, da - anders als bei den DynDNS Diensten - bei RFC2136 immer die WAN IP benutzt wurde. Wenn man aber vorne dran noch einen Provider Router und damit ein privates Transfernetz hatte, wurde in den A Record immer die private 192er (oder sonstige) IP der pfSense eingetragen anstatt der IP, die sie extern beim Provider hat. Das Feld wurde eingebaut um das Verhalten wie DynDNS und Co zu simulieren. Dazu wird ein externer Check gemacht, wie die IP nach außen ist und das statt der WAN Adresse eingetragen. Grüße

Das ist - sofern die DSL Lines jetzt schon sauber funktionieren - eigentlich kein direktes "Routing" Problem. Was du konfiguriert hast, geht aber nicht. 2 Interfaces dürfen nicht eine IP aus dem selben Subnetz haben! (Dürfen schon, aber nur in speziellen Fällen in spezfischen Konstellationen und das hat nichts mit deinem Problem zu tun). Wenn bei dir Outdoor und LAN wirklich ins gleiche Netz sollen (warum?), bleibt eigentlich nur eine Bridge über LAN und Outdoor. Der Traffic für den Outdoor Bereich (entsprechende Einteilung im DHCP vorausgesetzt), kann man dann per PolicyBasedRouting in einer extra Firewall Regel setzen. (Eine Pass Regel mit Source <von-bis bereich="" des="" dhcp="" für="" outdoor="">zu Destination any und in advanced Settings dann nicht Default Route, sondern direkt das Gateway für DSL2) Grüße</von-bis>

@Dodger: Über 2.1 bis 2.1.3 hin alle. @virago / Dodger: Ist bei uns ähnlich, allerdings haben wir da 2 SSDs als RAID1 was transparent an der pfSense als 1 Laufwerk ankommt (problemlos). Einzig einige Netzwerkeinstellungen mussten wir tunen, da durch die vielen (hyperthreaded) Kerne der CPU es ein Problem mit den MBufs gab. Das ist aber auch unter doc.pfsense.org zu finden. Einen SingleCore Kernel gibt es inzwischen allerdings nicht mehr, also keine Angst. Das war noch 2.0 und früher. Mit 2.1 gibt es nur noch einen Kernel, der automatisch multicore nutzt. Unser Problem mit den MBUFs wurde auch durch die Kerne verursacht, weswegen ich die Installation mit BootOptionen durchgeführt habe, um an den CPUs nichts drehen zu müssen. Hintergrund war, dass die Puffer pro Kern und Queue verteilt werden und es bei vielen Kernen dann zu viel für die Default Settings wurde. (https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards) Grüße

Der BSD network stack ist da etwas anders als Linux. Wenn aber bspw. das Netz 172.25.1.0/24 hinter dem Router 192.168.0.200 steht, würde ich das als Netzroute auch genau so in die pfSense eintragen und erwarten (war in der Vergangenheit auch immer so ;)), dass die Pakete dann auch direkt an 200 geschickt werden. Gruß

@robby: Aber kommst du bspw. von extern auf die pfSense (sollte nicht, es sei denn du hast den Port auf WAN geöffnet)? Bzw. siehst du einen fehlgeschlagenen Portzugriff auf 80/443 auf die pfSense WAN IP wenn du drauf zugreifst? Ich versuche nur auszuschließen, dass da überhaupt was ankommt ;) da aber das NAT ja läuft von innen nach außen gehe ich mal sicher davon aus. Die andere Frage wäre, ob du in den FW Logs was siehst. Also bspw. mal testen bei "wieistmeineip" o.ä. wie deine aktuelle IP ist und schauen, ob die im FW Log auftaucht beim Zugriff auf die media-Maschine. @csamaggi: Dein Setup sieht irgendwie verbogen aus. Die vmWare Einstellungen sollten schon wie bei robby aussehen, wenn deine VM nicht im LAN, sondern direkt "neben" der pfSense auf dem WAN Interface hängt, wird das nie funktionieren, da Hetzner einen MAC Blocker auf dem Port hat und die VMs dann nicht raus können. Deshalb muss man ja den Spaß mit Routing VM machen :) Grüße Jens

Erhellst du uns auch, wie?

Danke, daran lag es. In vorherigen Versionen musste der Haken nicht gesetzt sein.

Hi, sie scheint sich manchmal auf 115200 zu stellen. Das kannst du aber auch fest einstellen dann ist das vorbei.

Ich habs jetzt über PPPoE laufen. Mal sehen, ob der Fehler wieder auftritt

Hi! Wie kann ich das Durchsatzproblem erkennen/testen? Gruß Thomas

Hallo tommysense, vielleicht schreibst Du wirklich mal genauer die Config hier rein (vom CP, wo sind welche Netze konfiguriert, was hängt an welchen Port …) Hast du noch mehr WLANs, in die sich die Clients evtl. unbemerkt einbuchen können? Was passiert, wenn du alle User der CP-Gruppe in pfSense entfernst? Du tippst selbst auf DNS. Was hast Du da denn konfiguriert?

Entweder du erlaubst das der DNS Forwarder localhost benutzen darf oder du gehst in General Setup und setzt den hacken bei Do not use the DNS Forwarder as a DNS server for the firewall.

Servus, keiner ne Idee? Ich habe das Problem noch nicht lösen können. Es ist auch egal ob der Squid transparent ist oder nicht - es kommt immer invalid request. Für nen Tipp wäre ich sehr dankbar. Grüße

@JeGr: UDP/67 und /68 sind DHCP Pakete. Da läuft was anderes falsch, wenn die im Log auftauchen, es sei denn du hast 2 LANs und das eine Segment versucht ins andere zu funken. nein, hab nur eins, em0 wan und em1 lan, es hängen allerdings zwei router als ap drann. proto udp src any port 67 wo muss ich das eintragen? (bin noch der vollnoob^^) @viragomann: Broadcasts sind nur für das eigene Netzwerksegment bestimmt und werden daher an der pfSense Schnittstelle geblockt. Zuständig ist die "Default deny rule", also die die auf Pakete ansetzt, die von keiner anderen Regel abgehandelt werden. Diesen Traffic per Regel zu erlauben wäre sinnlos. Wenn du die Logs nicht sehen magst, kannst du sie mit einer Block-Regel im abfangen, für die du keine Logging aktivierst. Wo abfangen? (da fehlt das Wo, grins) Aber eigentlich scheint dieser traffic normalerweise nicht auf?