Hallo Zusammen

Ich versuche nochmals meine vielen Fragen zu stellen :)

Ich habe eine 50Mbit sync Leitung und daher ist mein qInternet auch 50Mbit/s
Jetzt habe ich folgende Queues:
qACK, qOthersDefault, qP2P, qOthersHigh, qOthersLow
Wenn ich die % unter "Bandwidth" zusammen zähle komme ich aber nur auf 50%, sollte das nicht 100% sein?

Für was steht eigentlich die qOthersDefault? Diese Regel habe ich nur auf dem WAN Interface.

Unter Service Curve (sc) verstehe ich das m1 / d / m2 doch was ich nicht verstehe sind diese Möglichkeiten Upperlimit, time und share, wenn wird welches angewendet und für was?

Danke

Gruss DarkMasta

Hallo Till,

ohne weiteres wird das nicht machbar sein. Da du das Netz erst mit der pfSense aufspannst, in der das LAN residieren soll, könntest du auf der Fritzbox von UM nur via VLAN die WLAN Clients einsammeln und auf die pfSense routen - leider kann die FB aber keine VLANs und kein erweitertes Routing. Da man noch dazu auf der UM-Fritzbox keinen Einfluß auf die Firmware hat, wirst du da nicht wirklich weiter kommen.

Deine andere Variante wäre statt dessen eher die 7390 ins LAN zu hängen und dort das WLAN aufzuspannen. Evtl. kannst du hier die UM FB dazu mißbrauchen, den Repeater für die 7390 zu spielen. Aber ansonsten wirst du die WLAN Clients nicht hinter die pfSense bekommen. Ich selbst habe annähernd das selbe Setup im Home Lab, und hier ebenfalls die pfSense hinter der UM-Fritte. (allerdings in Hardware). Ich nutze die FB von UM nur als Gäste WLAN da ich diese eh nicht in den internen LANs haben möchte, für mehr traue ich dem Ding aber nicht ;)

Grüße

Hallo ma_fe,

das es nicht funktioniert kann ich nicht bestätigen. Die Synchronisierung mit einer DynDNS-Domain und auch das Nutzen eines Vouchers an der synchronisierten PFSense funktioniert. Nur nach dem Ausloggen (oder Timeout) des Nutzers scheppert es auf beiden Maschinen. Die Crash Reports habe ich ja aufgeführt.

Ich nutze 2.2.4 und mittlerweile 2.2.5

Das hat aber am Ergebnis nichts geändert.

Viele Grüße,

Volker

Richtig, aber was die Leute nicht sehen verstehen sie nicht.
Das mag durchaus sein…

Wenn man sagt Netz XY hat keine Verbindung mehr, wenn man LAN Kabel an Port 3 zieht ist das nachvollziehbarer.
...aber man sich als Techniker Lösungen aufzwingen lässt, nur weil es nicht-Techniker sonst nicht verstehen, macht es a) keinen Sinn und ist meistens b) unnötig kompliziert wenn nicht sogar c) schlechter/unsicherer gelöst. Mag jetzt in diesem Fall nicht unbedingt zutreffen, aber den Satz alleine lasse ich so ohne weiteres nicht als Erklärung gelten ;) Dann musst du ihnen es eben sinnvoll erklären. Die 8 Adern im Kabel können sie auch nicht sehen und gehen davon aus, dass die Pakete drin rumschwirren und irgendwo ankommen.:)

Es gibt auch für jedes Netzwerk einen eigenen Switch - die stehen hier eh schon rum  ;)
DAS lasse ich dann gern gelten ;)

Alle Drucker sollten für alle Clienten als Netzwerkdrucker zur Verfügung stehen.
Wie gesagt das liegt im Einzelfall am Drucker ob das "so einfach" geht oder nicht. Wenn die Geräte was taugen und per IP laufen sollte es kein Problem sein.

Wobei ich bei meiner Recherche auch Geräte gefunden habe, die 2,3,4... DSL Leitungen (auch von Verschiedenen Anbietern) per Multi WAN zusammenführen können und sich somit auch die Bandbreite erhöht - wenn ich das richtig verstanden habe.
Dann bitte ganz genau lesen, was sich da erhöht. Solange dein Anbieter (DSL) seine Leitungen nicht bündelt, funktioniert es rein technisch nicht einfach, 1+1+1+1 zu rechnen und 4 rauszubekommen. Wie oben gesagt, wird die Bandbreite dadurch erhöht, dass bspw. 2 gleichzeitige Clients auf 2 Leitungen verteilt werden und somit jeder seine Leitung voll nutzen kann statt eine halb. Was natürlich bei n Clients nocht mehr ins Gewicht fällt. Aber ein Client alleine wird durch 2x WAN nicht doppelt so schnell - außer in Ausnahmefällen, dass bspw. der genutzte Client eben bspw. seine Verbindungen mehrfach splittet und daher wieder auf mehrere DSLs verteilen kann. Bspw. HTTP Downloads via Downloadmanager in 2 oder mehr Teile gespaltet, kann dann auch beide Leitungen ausnutzen.

Wie gesagt sind das aber alles Sonderfälle. Man kann nicht bei allem davon ausgehen, dass mehrere Leitungen das Internet generell einfach doppelt so schnell machen. Auch andere Lösungen machen das nicht besser auch wenn sie mit viel magischem Einhorn-Feenstaub versuchen sowas zu basteln. Da wird dann einiges mit Proxies, Balancern und haste-nich-gesehen Kram gebaut, aber an der Technik lässt sich da auch nichts verändern :)

Hi,

danke für den Link.
Das Problem bestand einen Tag, nachdem ich ein Polling über das LAN Interface (Route) eingerichtet habe, nicht mehr.
Ich vermute, dass es eine Energieoption auf ESX Seite gab. Die habe ich auch von Balanced auf Höchstleistung gesetzt.

Viele Grüße
Tino

Und wie hast du es gelöst? :)

zu 3) Bei synproxy state würde das so ablaufen, ja. Die pfSense spielt dann vorgeschalteter Proxy und nimmt proaktiv schonmal die Verbindung an. Das ist auch der Grund warum man das im Normalfall nicht tun sollte, denn dadurch signalisiert du einem normalen Client, dass die Verbindung steht obwohl sie das noch nicht tut. Wenn jetzt dein Backend Server bspw. die Verbindung aber ablehnt, weil bspw. zu viele concurrent sessions laufen, dann hast du den Salat. Im Falle eines Angriffs mit Syn Flood hast du aber wie gesagt andere Probleme, so dass das dein kleinstes Übel ist ;) und dir statt dessen den sprichtwörtlichen Hintern retten kann.
Das Problem liegt ganz einfach darin, dass du Dinge vorgaukelst mit dem SynProxy, die nicht gegeben sind. Einem Client klarzumachen, dass die Verbindung jetzt doch nicht steht, nachdem du sie nach dem 3 Wege Handshake bestätigt hast ist schlichtweg übel. Deshalb die Links oben, einfach mal drüberlesen. Deshalb ist das nicht default, weil es nicht sinnvoll ist, nicht dem Standard entspricht und den Client verwirren kann, der sich seinerseits dann ggf. seltsam verhält.

Es blockt den Traffic, da es aber die pfsense erledigen muss ist meine Leitung trotzdem gefüllt, daher kein Schutz vor DDOS oder?
Nein. Schau dir mal das Filterlog an, was auf dem WAN Port einer pfSense alles anschlägt, sobald du die ins Netz hängst. Ganz schöner Salat, oder? Das ist alles Traffic der schon BIS zu DIR geroutet wurde. Nennt man gerne "Leitungsgrundrauschen". Je nach ISP kann das sogar schon in Megabit/Sekunde gehen. Das können alte Verbindungen sein von demjenigen, der die IP vor dir hatte, aber hauptsächlich sind es gerade in großen ISP Netzen Scans nach IP/Ports, nicht richtig konfigurierte Server oder nackte Kisten, die einfach so im Netz hängen, Windows AD/Netbios Kram, Security Scans und/oder Botnetze & Malware, die IPs nach üblichen Einfallsvektoren absuchen.
Selbst wenn du den Traffic bei dir nicht annimmst, die Pakete sind ja schon da. Der DHL Bote stand an deiner Tür, du hast nicht aufgemacht, und er ist wieder weg. Nur dass es nicht ein Bote sind, sondern ein paar Millionen. Ganz schöner Stau in deiner Straße ;) und das wo du doch gar nicht da bist :) Deshalb ist es völlig egal, ob du an deinem Border Gateway (respektive deiner pfSense) filterst oder nicht. Wenn dir jemand eine entsprechende Masse an Pakete auf deine IP schickt, geht dein Link unter und dein Provider mit.

"Schutz" vor DDOS gibt es lediglich, wenn du so groß bist, dass du selbst (bspw. via BGP) routen kannst wie du willst. DANN hast du die Chance bspw. den Traffic auf deine Website über andere Kanäle und Upstream Provider zu routen und vor allem kannst du versuchen mit deinen ISPs zusammen die Quelle zu orten und zu blackholen. Aber wenn du lediglich "Endkunde" bist, hast du nicht viel Möglichkeiten außer bspw. Dienste wie bspw. cloudflare zu nutzen. Sprich deine Website hinter ein Netzwerk aus vielen großen Kisten zu packen, die den Paketsturm für dich aushalten.

Moinsen,

wie muss ich das mit dem Proxy einstellen genau? Er sollte vorerst schon als transparent laufen, da er von den PCs und Handys nicht umgangen werden sollte. Und das geht nun mal denke ich nicht anders, oder denke ich hier grade um falsche Ecken?

Langsam läuft der Thread hier voll mit 27 verschiedenen Themen, aber nun gut, ist ja auch im Titel allgemein gehalten. Es geht ja um meinen Netzaufbau  8)

Ich habe noch ein Verständnissproblem mit Routing und Gateway…
Muss ich mehr einstellen, als das Gateway für WAN? Also das ist ja klar, das ist die Fritte die am Inselnet hängt. Also bislang noch die 192.168.178.1. Das ist auch als default GW markiert. Mehr brauche ich nicht einzurichten, oder? Alle anderen (LAN und DMZ) gehen über das 178.1 GW raus, richtig?

Besten Dank, Marc.

Hallo,

es funktioniert.

Danke

Ich habe den Fehler gefunden:

Ich hatte vergessen für die Clients die nicht ins Inet dürfen DNS zu erlauben. Somit kann es nicht funktionieren, da Teamviewer mit FQDN´s arbeitet.

Komischerweise funktioniert es mit TCP auch… scheinbar geht beides, es sei den man deaktiviert in den erweiterten Einstellungen von Teamviewer "UDP erlauben".

Die Default NAT-Einstellungen habe ich deaktiviert und zu meiner Übersicht neu angelegt. Den ich habe viele Subnetze zu verwalten. ;D

Ich führe das hier mal zu Dokuzwecken weiter. Vlt. kanns ja mal jemand brauchen.

Bin gerade dabei von meiner Debian VM, die in der pfSense-DMZ steht (10.0.0.3) auf das Gateway von Hetzner zu pingen.

Dabei stelle ich fest, dass es wohl Paketverluste gibt.

Die Ping Sequenz springt zb. von icmp_seq = 105 auf 111, 116, 118, 129, 133 etc.

Breche ich den ping nach ca. 1-2 Minuten ab habe ich 47% Paketverluste….

Interessant und leider eine Spaßbremse... ;-)

Auch wenns leider nicht viel gebracht hat, gern geschehen.

Dann solltest du ja auch 2 Gateways für multiple WANs haben. Du musst dann auf dem DMZ Interface auf dem der Mikrotik hängt abgehend die Regel eintragen, dass er wo-auch-immer hin darf und dabei sein Gateway überschreiben mit dem Telekom Gateway (unter Advanced Settings in der Firewall Regel). Stichwort für die Doku ist dabei policy based routing.

Hi,

am Ende deines Posts fehlt der Dank, dass jemand bis dahin gelesen hat. Das verdient doch auch schon Anerkennung.  ;)

@Jorval:

A Kein Auto NAT
also hab ich einfach eine Route an der 2.Sense im Branch1 ins direkt ins Internet gesetzt. und die Clients die das dürfen sollen in einen Alias gepackt und eine Regel erstellt die den Clients diese Netze erlauben sollen. Klappte aber nicht. Ich bin nicht gleich darauf gekommen einen Blick ins Firewall -> NAT zu werfen aber da war keine Regel automatisch erstellt worden. Sollte die Sense das nicht eigentlich tun? Oder gibt es eine Einstellung die vorher dafür aktiviert werden muss? Ich habe jedenfalls auf Hybrid umgestellt und das NAT dann von Hand eingerichtet, Ich bin mir aber sicher das die Große im Hauptbetrieb das allein gemacht hat die steht auch auf Automatisch und hat Einträge generiert.

Automatisch erstellt werden nur Regeln fürs WAN, nicht für andere Interfaces. Da ist das auch nur selten gewollt, und Wünsche von den Augen des Admin abzulesen, gibt es erst im übernächsten großen Release.  ;)

@Jorval:

B Mal gilt die Regel mal nicht.
Hat mit der gleichen Sache zu tun. Die oben erwähnte Regel funktionierte Tadellos. Am nächsten Tag ein aufgeregter User das Programm geht nicht?! Regel Überprüft, alles richtig meiner Meinung nach.Das Log zeigt mir aber Blocks an wenn der User das Programm startet. Die Pakete landen in der default ipv4 deny rule? Regel einmal anfassen, speichern Apply und Sie funktioniert wieder. Auf nachfrage im IRC antwortete jemand das dies passieren könnte wenn ein FIN Packet für eine Bereits terminierte Verbindung ankommt (z.b. wegen packetloss) Ich verstehe aber nicht warum das gleich die ganze Regel außer kraft setzen sollte?

Was für Flags habe die gelockten Pakete im Log?
pfSense loggt nur die ersten Pakete einer Verbindung, also bei ordnungsgemäßer TCP Verbindung nur die SYN Pakete. Andere TCP Pakete stehen nur im Log, wenn die Verbindung bereits geschlossen wurde oder nie aufgebaut wurde.
Könnte damit in Zusammenhang stehen:
https://doc.pfsense.org/index.php/Why_do_my_logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection

Falls die Pakete aber in Ordnung sind, kann es sein, dass die VPN Verbindung unterbrochen wurde, ehe das Problem auftritt? Check mal das Log danach.

@Jorval:

C Eigentlich wollte ich den kompletten Verkehr durch den Tunnel an den Hauptstandort haben wie es auch bei der abgelösten TKom Verbindung der Fall war. Das im OVPN Server auf der HauptbetriebsSense eingetragene push "route 0.0.0.0/0" hat er auch min. 1 mal gezogen, das habe ich beim Diagnostic -> Routes gesehen, aber dann war ich so mit Problem B beschäftigt und hatte einiges geändert das ich das erst einmal nicht weiter verfolgt habe. Jetzt steht das Default Gw aber nur noch ins inet. Das ist für mich generell auch ok da wir vllt. einmal Proxy vor Ort nachrüsten möchten, aber auch hier verstehe ich nicht ganz warum er die Anweisung dropt. Vielleicht hat jemand einen kleinen schubs ins richtige log für mich ?

Warum das nicht geht, kann ich dir auch nicht sagen, aber Gegenfrage:
Warum arbeitest du bei einer dauerhaften Verbindung überhaupt mit push route??
Die Netze, die über die VPN geroutet werden sollen, kannst du ja in der Client Konfiguration, nehme an das ist Branch 1, eintragen (Remote Networks), bzw. ebenso am Server. Das hat faktisch den gleichen Effekt, als ob du es in die Routingtabelle einträgst und funktioniert immer (wenn die Verbindung steht).
Andere Routen sind für diese Netze ohnehin nicht vorgesehen, denke ich.

@Jorval:

D Kein ssh durch den Tunnel.
An Branch1 geht auf Seite der Benutzer soweit alles, Die User machen RDP Verbindungen ins RZ das RZ schickt Druckaufträge in Branch1 die Kollegen kommen via Browser und Proxy ins Internet und selbst Seiten die nochmal hinter einem NAT am Hauptstandort liegen funktionieren ohne Probleme.
Ich kann allerdings von Standort Branch2 wo nun die IT sitzt keine ssh Verbindung mehr zum Debian Server an Standort Branch1 aufbauen. Manchmal kommt nach langer wartezeit wenigstens die Passwort abfrage. ping und tracepath laufen den korrekten weg. Ich kann weder den xenserver 192.168.1.2 noch den debian 192.168.1.3 connecten. ssh zur Sense 192.168.1.1 funktioniert hingegen perfekt (zu meinem Glück)
Vom Hauptbetrieb das selbe Spiel die Sense in Branch1 ist erreichbar die beiden anderen (Xen,Deb) leider nicht.
Das OVPN hat ja ein Telekom VPN abgelöst.

Die pfSense erreichst du per ssh über den VPN Tunnel? Wenn ja, stimmt die Threadüberschrift nicht und die Ursache ist möglicherweise auch nicht beim Tunnel zu suchen.

Gleichzeitig mit der Umstellung von der früheren Lösung habt ihr die neue pfSense auch virtualisiert. Vielleicht ein XEN Problem? Schau dir mal diesen Thread an und prüfe die Empfehlungen:
https://forum.pfsense.org/index.php?topic=88467.0

Grüße

@tripelm:

Hallo zusammen,

ich hoffe das mir hier jemand weiterhelfen kann.

zuerst einmal meine captive portal page:

<title>Kunde</title>

-->

|
                       Willkommen im Gast WLAN von Kunde.
                    |
|
                       Kundenpdf
                    |
|
                       Kundenpdf
                    |
|
                       Kundenpdf
                    |
|
                       
                        Durch drücken des Bestätigen Buttons akzeptieren Sie unsere AGB.
                       
                       
                    |

Nun besteht das Phänomen das wenn der Kunde auf den Button klickt nichts passiert. Die Willkommens Seite bleibt
weiterhin geöffnet und sonst geschieht nichts.

woran könnte das liegen?

Danke im Voraus

Also so auf die schnelle würd ich sagen, fehlt bei Dir:

Wobei XXXX für den Namen des Captive portals steht

na am download manger solls nicht scheitern

Selbst den kann man tunen auf mehr als die normalen bzw. üblichen 15 simultanen Kanäle
hoch setzen.

Und ein Cache Proxy hätte ja auch mit im Spiel sein können.