Ja, die Sache mit den Adressen beim Gateway hatte ich ja erwähnt, die ist aber generell bei HA Setups immer wichtig und zu beachten. Nicht nur bei Gateway Gruppen, sondern auch bei u.a. solchen Punkten wie Outbound NAT (da ist automagisch ja auch immer auf die IF Adresse genattet), bei Services, die sonst direkt auf der Sense laufen und deren IP nutzen, Proxy, etc. etc. - bei einem HA Setup muss man da gern nochmal alles überfliegen und wirklich nur da Interface Address auswählen, wo es wirklich gewollt ist. Ansonsten braucht es fast überall (meistens) die CARP IP.

Ist auch ein Punkt der uns bei Support Calls und Audits immer wieder auffällt (und auch die Fragen aufwirft, warum nach Failover XY nicht läuft). :)

Grüße

Danke für die tollen Tips. Habe natürlich einen kleinen Raspi immer laufen. Werde da gleich mal NFDUMP und NfSen installieren. Mal sehen was da raus kommt.
Aber rrd kann ja auch nicht falsch liegen.
Witzig ist, dass mit 1&1 an der Hotline den RRD Wert aus dem Vormonat bestätigt hat. Der stimmt also. Dann kann doch der jetzige Wert auch nicht falsch sein.
Ist zufällig nach dem Kündigen des Vertrages doppelt so hoch.

Melde mich wieder :)

hi,

ich hab nun mit den Verschlüsselungsalgorithmen (AES128/256/SHA1 usw.) herumgespielt und angepasst - seitdem läufts einwandfrei!
lg

Der graue Balken in der quad9 zwischen 22:57 und 22:58 ist entstanden, als ich die Aufzeichnung pausiert habe um beide Graphen synchron zu haben. Das war mal nicht das Netz.
Die generell erhöhte Latenz vor 23:00 sehe ich hier, wenn ich selbst eine größere Menge Daten auf dem VDSL generiere - in diesem Fall waren das 600MB Updates IIRC.
Die kleinen Spitzen dazwischen sorgen mich jedoch, so dass ich momentan ein neues VDSL-Modem in der Pipeline habe um das vorhandene Allnet ALL126AS2 mal zu tauschen.

Nicht erklären kann ich mir die PLs zu 217.0.117.216 in einem Graphen während der andere diesen Router ohne Aussetzer listet.

Alte Techniker-Weisheit dazu: Wer misst misst Mist. Wer viel misst misst viel Mist.

OK, vielen Dank.
Dann werd ich das mit den virt. IPs mal angehen.

Danke für die schnelle Hilfe.

Gruß Sebastian

Danke für den Hinweis jahonix.

Du hast natürlich Recht.
Besser wäre eine Regel, die private IP-Adressbereiche erlaubt.
Ich habe mich beim Erstellen der Regel wahrscheinlich zu stark an dem Screenshot von DasBrot orientiert, in dem mit Invert match gearbeitet wurde.

Den Rest blockieren kann man machen um ganz sicher zu gehen. Wenn allerdings nur die RFC1918 Regel existiert wird sowieso alles andere geblockt.

Ich habe meine erste Antwort editiert.
Link zum alten Screenshot, auf den sich die Antwort von jahonix bezieht: ALTER SCREENSHOT

Super hat funktioniert.

Danke

@mrsunfire:

Ich habe derzeit noch kein VoIP Telefon. Ich dachte erst an ein Cisco SIP Gateway um dort meine Telefone anschließen zu können, aber vielleicht könnte das ja auch meine Sense übernehmen, daher die Frage ;)

Hallo,

wenn ich das richtig verstehe, hast Du zur Zeit noch die gute alte Telefontechnik. Analog (a/b) oder ISDN.
Wenn dem so ist, benötigst Du auf jeden Fall entweder:

Ein neues VoIP Telefon welches es in den verschiedensten Geschmaksrichtungen und Preisen gibt Einen VoIP nach analog Wandler (ata) z.B. Cisco Oder einen VoIP nach ISDN Wandler, hier sollten sich recht billig Lancom 1722 schießen lassen, da diese kein AnexJ unterstützen und aus diversen Artzpraxen und Firmen raus fliegen.
Damit hast Du dann den technischen Übergang VoIP zu nicht VoIP gelöst.

Die Geräte können alle hinter einer pf betrieben werden, ABER dazu bitte an die Anleitungen

https://forum.pfsense.org/index.php?topic=120063.0

halten.

Die Crux am VoIP Standard ist unter anderem das die Normung wohl lediglich die Schreibweise der Buchstaben V o I P regelt und der Rest ist Auslegungssache

Und im Routing bzw NAT lediglich die UDP Header bezogen auf die IP Adressen und Ports angepasst werden.
Dies führt in den verschiedensten Szenarien zu Problemen da in der "Nutzlast" des UDP (TCP bei der Telekomik) ebenfalls Ports und IP Adressen sind, welche nicht angepasst werden.
Ein VoIP ALG ist aber auch Bäh, da hier nicht nur der Header verändert wird sondern auch die Nutzlast. Um dort dann Fehler zu finden bedarf es an viel Zeit, Wireshark und Kenntnis das VoIP Protokolls

HornetX11 mobil

@JeGr:

Ui, das ist mir noch nicht mal aufgefallen bisher 8-(

Ist wohl leider immer noch so. Ich hatte das erst vor 2 Wochen selbst bei unserer Labor 6490 Cable versucht, endlich v6 durchzurouten. Positiv: man bekommt es endlich recht gut hin, dass man ein /64er auf jedem Interface Bein abbekommen hat (WAN bekommt ein /64, nutzt aber zum routen die fe80, LAN, TEST, TEST2 bekamen alle durch ID 0, 9, f und Track Interface dann eigene Netze).
Die schlechte Geschichte war dann: abgehend klappt der ganze Kram, aber eingehend kann man sich zu Tode grützen, denn die nachgelagerten Netze werden im IP Filter der Fritzbox einfach nicht durchgelassen. Man muss wirklich MANUELL jedes einzelne Host Suffix eintragen. Erst nachdem ich den 64 Bit Host Teil der IP6 von einem Testsystem zur Freigabe in der Fritzbox eingetragen habe, konnte man von außen halbwegs die v6 Strecke pingen. Und ich habe nur begrenzt bis gar keine Lust, jedes einzelne Gerät, dass potentiell eine v6 erhalten kann jedes Mal in der Fritzbox "quasi" anzumelden. :( Es fehlt die Möglichkeit einfach ein gesamtes Netz/Prefix freizugeben bzw. durchzurouten. :(

Gut zu wissen - danke für die Info.
Da kann man sich schon mal totsuchen 8-<

Ciao.
Michael.

Wie gesagt, nach der IP VON der es kam oder ZU der es ging. Ich weiß ja gerade nicht was du suchen möchtest ;)

Sorry, ich lese den NIC zuerst wirklich immer so bis dann ein "ach nee" einsetzt. Jetzt ist das hoffentlich auch erledigt.

^das und
wenn in der pfSense nur das eigene WAN als Gateway konfiguriert ist (default), dann weiß sie ja nicht, wohin sie Pakete, die über einen anderen Router zu ihr kommen, beantworten soll.
Also erst den anderen Router als eine weitere Gateway IP eintragen (nicht default machen, Monitoring kannst Du vermutlich ausschalten) und dann eine Static Route zum entfernten subnet über dieses Gateway setzen.

Wenn Du zwei Seiten miteinander verbinden willst, dann musst Du routen. Das geht nicht im gleichen Netz, dafür braucht es zwingend unterschiedliche Netzbereiche.
Gleiche Netzbereiche miteinander zu verbinden bedeutet bridgen (stretched LAN). Bei einer Site-to-site Bridge musst Du wiederum aufpassen, dass keine IP doppelt vorkommt. Das macht man gelegentlich, um ein Netzwerk in ein DataCenter zu "verlängern". Zwei bestehende Produktiv-Netzwerke zu bridgen wäre … mutig.

Hallo Blitz,

und 2) deshalb, da dir ansonsten jede Möglichkeit fehlt, Dienste konkret einem WAN zuzuordnen. Da jedem WAN Interface ein Default GW zugeteilt ist, kannst du bei deiner Variante mit einem WAN und 2 Gateways darin keinen Service auf bspw. der Sense konfigurieren, der Default über WAN2 rausgeht, da dein WAN-gebundener Service stets das WAN Default GW nehmen würde. Das zu überschreiben wäre mit Floats etc. zwar theoretisch denkbar aber mühselig und unpraktisch, deshalb wird in jeder Doku bei MultiWAN auch zumindest von 2 Schnittstellen (egal ob phyisch oder VLANs) gesprochen. Ich würde 2 WAN GWs im gleichen WAN Subnetz vor der Sense als fehleranfällig betrachten bei der Umsetzung.

Darum würde ich das eher auf eigene Interfaces packen :)

Servus,

du hast ja prizipiell 2 Stellen wo man in deinem Fall den Primären Anschluss auswählen kann.

Einmal Direkt unter Routing->Gateways und einmal unter Routing-Gatewaygruppen.

In deinem Fall ist es völlig irrelevant, welches Gateway unter "Routing>Gateways" als Default eingestellt ist, es ist einzig entscheidend welches Gateway in der Routinggruppe die höhere Priorität besitzt.

Wenn also dein Ovpn-Client primär über Wan2 rausgehen soll, muss in der angebenen Gatewaygruppe Wan2 die Stufe1 (Tier1) und WAN1 die Stufe 2 (Tier2) besitzen.

Wenn du es genauso eingestellt hast, sollte es dann auch funktionieren. (So die Theorie)

Achso nochwas, wenn die Verbindung über WAN1 schon aufgebaut ist und erst dann WAN2 wieder aktiv wird, musst du aller Vorraussicht die VPN Verbindung kurz unterbrechen. Da eine bestehende Verbindung nicht geswitcht wird.

Gruß
Rubinho

Ja wenn du die Sense in den Switch der Fritte einsteckst und deinen eigentlichen Switch mit Clients an das LAN der Sense brauchst du keine VLANs.

Ansonsten hat die DHCP Geschichte etc. Rubinho schon völlig beantwortet :)

Servus,

das entspricht ja quasi dem, oder?

diese dann in Regeln auf deinem LAN Interface einbinden und damit dann den Traffic routen -> PBR (Policy based routing). Einfach eine Regel VON "LAN net" nach "LAN_der_anderen_Seite" via (Adv. Settings öffnen, GW auswählen). Damit wird dann jeder Traffic der darauf matched durch die Tunnel gezwungen.

Ist auch so gemacht, funktioniert nur leider nicht. Ich kann per tcpdump. auf dem vm-Host sehen, wie die Ping-Pakete durch das normale WAN-Gateway rausgehen und irgendwann vom Rechenzentrums-Router verworfen werden, da private subnetze.

Diese PBR-Regel greift so leider nicht. Ich verstehe auch nicht warum, da diese ja ziemlich eindeutig ist. Kann es sein, dass sich "LAN" da nicht zuständig fühlt, da weder ein Interface eine IP in diesen Subnetz hat, noch eine "normale" routing-Regel vorhanden ist, die das ziel-subnetz beschreibt?

Wie kann ich feststellen, wie weit die Pakete kommen?

LG, Freisei

Hängt stark von der Leitungsbreite und der Performance der Kisten ab. Wenn das kein Problem darstellt würde ich persönlich OpenVPN den Vorzug geben. Einfacher und schneller einzurichten und ggf. kannst du damit auch durch PBR bestimmte Sachen anders routen als definiert. Einfach flexibler.

https://forum.pfsense.org/index.php?topic=137103.0 alles lesen, nicht nur die erste Seite.

Aufgrund der Frage hatte ich angenommen das Du von den Netzwerkkenntnissen vielleicht noch keine VLANs eingerichtet hast.

Das ist zwar nicht schwer setzt aber einen Managed Switch voraus und hat eine gewisse Lernkurve.

Ich kann aus den Informationen auch noch nicht erkennen das Du das überhaupt brauchst.

Hast Du schon mal VLANs eingerichtet und brauchst Du überhaupt getrennte WLANs?

Wenn nein kannst Du den AP einfach an Deinen Switch hängen und fertig. Administration ist sowieso getrennt.

Brauchst Du getrennte WLANs dann wirst Du um VLAns nicht herum kommen. Das ist dann aber nicht einfach so eben mal so mit zwei screenshots gemacht.

Gruß

Hagen