@Grimson: Da stimme ich dir zu, schade nur, dass es keine Möglichkeit gibt, seinen he.net Tunnel statt über GIF zu "routen" statt dessen via routing-push (bspw. DynDNS Mechanismus) einfach direkt auf seine externe IPv6 der Telekom o.ä. zu routen :) Dann wäre auch das Problem mit MTU und derlei erledigt :)

Nur zur Info,

auch ich hatte das Problem, dass das Udate auf 2.4 via Webif auf einer APU1 in die Hose ging.
Ein Cleaninstall auf 2.4 funktionierte jedoch ohne Probleme.

Man sollte also in der Nähe sein und mit einem USB-Stick@PFS2.4 bewaffnet sein, wenn man es via Webif versucht.
Natürlich Backup vorher nicht vergessen, jaaanz wichtig !

Ja, so habe ich das auch jetzt alles konfiguriert. Bis eben auf den VLAN 7 Tag. Den könnte das Zyxel auch eliminieren, dann bräuchte ich es nicht mehr in der PFSense.
Ich lass das erst mal so laufen…  8)

Wenn ich Zeit und Lust habe, probiere ich es mal aus.

Danke nochmal für die Hilfe!

@pfsnooker:

Aber da schließt sich gleich die nächste Frage an: Bei mir wird im Idle 60°C angezeigt und ich frage mich nun, ob das "normal" für die passive Kühlung ist?

Meines Wissens völlig in Ordnung, da der Chip für 90°C ausgelegt ist. Bei mir schwankt das zwischen 50 und 60, viel höher war es auch unter Last nicht. Und bei mir steht das Gehäuse noch auf einem Teppichboden (wird sich bald ändern).

Ich glaube, bei PCEngines.ch gab es im Support Forum schon einen Thread dazu, daher habe ich die  90°C. Wenn Du an ein Laptop denkst, da sind unter Last Temperaturen von 90 und höher völlig normal. Mittlerweile hab ich den Thread gefunden:
http://www.pcengines.info/forums/?page=post&id=795B2ACC-F4B0-4181-9B4A-54EC757D4001&fid=DF5ACB70-99C4-4C61-AFA6-4C0E0DB05B2A

Hallo und Guten Morgen,

habe nun einen funktionierenden Weg gefunden den unerwünschten Traffic zu verhindern. Und zwar nutze ich Domain Overrides des DNS Resolvers um die Domän nwsvr.com auf 127.0.0.1 umzulenken.

Somit können die WebCams nun nicht mehr den WansView DDNS Server erreichen. Ganz lieben Dank an alle die mit nach einer Lösung gesucht haben.

Grüße M.

ich würde hier jetzt - wenn die Clients es unterstützen (also alle 2.4 sind) - auf AES-GCM-256 gehen mit SHA384. GCM wird mehr aus AES-NI herausholen können und daher die CPU nicht so stark belasten wie CBC - wie es auch schon bei IPSec war. Damti man aber nicht alle Clients auf einmal rekonfigurieren muss, kann man via NCP jetzt eben beides hinterlegen - das was bislang aktiv ist und das neue - so dass man das schön umstellen kann ohne jemand bei der Verbindung plötzlich abzusägen :)

Manchmal sind es die kleinen Dinge :)

@un1que:

Bitte korrigiert mich, wenn ich falsch liege, aber ich habe schon an mehreren Stellen gelesen, dass in erster Linie ein Client-seitiges Update kommen muss, weil der Angriff über die Clients stattfinden würde. Wenn ich mir nun überlege, wie viele Android Smartphones/Tablets nun ohne dieses Sicherheitsupdate werden leben müssen…

Bei dem meisten Androids mit altem Stand bis 4.2.x ist das doch egal. Die Dinger sind meist schon so verseucht, da kommt es den weiteren Bug eh nimmer an. Bei 5+6 sieht es aber auch nicht rosig aus.
Oftmals hilft hier nur noch ein "community-rom update" weil von den Herstellern nichts offizielles kommt.

moin, habe mal eine neuinstallation mit der 2.4 gemacht, jetzt scheint alles wieder zu gehen.
wie makiere ich was wenn es erledigt/gelöst ist?

Welchen DNS die pfSense benutzt - das heißt der DNS Client - für den gibt es, soweit ich weiß, kein Log.
Testen kannst du das aber mit einem DNS-Lookup auf der pfSense:
Diagnostics > DNS Lookup. Hier werden die verwendeten Server nach ihrer Prio aufgelistet, d.h. der erste wird verwendet, sofern er antwortet.
Oder mit dig in der Shell oder im Command Prompt in der GUI, Diagnostics > Command Prompt. Bsp. "dig google.com" liefert bei Server den abgefragten DNS.

Ich weiß jetzt nicht, was du mit der Sache bezwecken willst, aber wenn du auf der pfSense den Resolver verwendest, um DNS für die Clients bereitzustellen, kannst du da mit "Outgoing Network Interfaces" einstellen, über welche Interfaces DNS-Anfragen rausgeschickt werden.
Wenn du einen VPN-Client installiert hast, um deine wahre IP zu verschleiern, sollte die DNS-Abfrage aber auch über die VPN geschehen, ansonsten hast du ein DNS-Leak.

Grüße

Naja weniger finanziell meist eher gewachsen oder komplett anders aufgebaut. Vielleicht steckt auch mehr dahinter, anyway :)

PAL - Problem anderer Leute :D In dem Fall die Netzwerker beim Anbieter/Provider ;) Wenn die mit v6 ähnlich arbeiten wie hier mit v4 gibt das Spaß :D

Aber back to topic, ich will das hier ja nicht komplett OT bringen :)

Ein entferntes Gerät (nicht lokal) soll mit einem Dienst im lokalen Netzwerk sich unterhalten können.

Ein Gerät (PC/NB) oder ein Netz? Das ist ein Unterschied.

VPN, welches aber auf der entfernten Seite schwer einzurichten ist

Nur wenn es das ganze Netz und nicht nur ein Gerät ist. Ansonsten wäre ein OpenVPN Zugriff gar kein Problem.

zusätlich müsste ich dem PFsense beibringen nur einen bestimmten Port durchzulassen

Warum? OpenVPN läuft auf der Sense selbst. Die FB schreibst du gibt alles weiter (exposed Host) ergo musst du erstmal gar nichts "durchlassen", sondern nur den Zugriff auf den OpenVPN Server der Sense erlauben.

Eine NatRegel im Pfsense erstellen mit dem Port und hier ebenfalls als Source die entfernte IP eintragen.

Du kannst als Alias auch ein Hostname eintragen, der wird dann alle x Minuten aktualisiert. Wenn sich die Dyndns Adresse ändert würde einige Minuten später auch der Eintrag in der Sense ändern und du hättest theoretisch wieder Zugriff. Trotzdem ist das natürlich ein wenig wacklig gegenüber einem simplen VPN Zugang, der sich sehr einfach einrichten und konfigurieren lässt, damit auch nur dieser eine Zugang erlaubt ist.

Gruß

Was steht im PPP Log wenn die Einwahl nicht geht?

Was für Hardware verwendest du? Zufällig einen Realtek Chip fürs Ethernet? Dann ist das nix neues das das Interface öfters mal hängt, in dem Fall gibt es zwei Möglichkeiten:

Einen atuellen Realtek Treiber selbst kompilieren und in der pfSense nutzen (suche einfach mal im Qotom Thread im Hardware Forum), das hilft manchmal.
Den Realtek Müll deaktivieren und ne ordentliche Intel Karte nutzen, das ist die bessere Lösung wenn dein System Platz dafür hat.

Ich denke das ist einfach ein Erklärungs/Verständnisproblem. Radius kann sich die Daten AUS einer MySQL Datenbank als Quelle holen, genauso wie Radius auch LDAP oder ein AD befragen kann nach Userdaten. Es schreibt aber nichts IN eine Datenbank, das ist gar nicht der Job von Radius.

Man kann mit dem Freeradius Package also Authentifizierung via Radius machen (was diverse Dinge ermöglicht, die andersweitig nicht oder nicht so einfach möglich sind), wenn dann aber die Authorisierung des Users von Radius via SQL/LDAP/egal erledigt wird, dann reicht agiert Radius an der Stelle nur als Vermittler. Radius ist aber nicht dafür zuständig, diese Verzeichnisse oder Datenbanken zu befüllen. Dafür sind LDAP Frontend, AD Benutzermanager oder eben ein DB Frontend für die MySQL nötig.

Auch die Auth-Methode der pfSense ändert daran nichts. Hier wird nur bspw. Radius, LDAP o.ä. als Auth Methode des User Managers eingetragen, damit ist dann der Login in die WebUI via Radius/LDAP/etc. möglich. Aber auch dann werden Benutzer, die in der WebUI LOKAL angelegt werden, auch nur weiterhin lokal gespeichert. Wenn Daten aus externen Quellen herangezogen werden, dann sind auch diese externen Quellen für ihre Verwaltung zuständig, nicht die pfSense.

Grüße

Noch sinnvoller wäre, dass man einfach zu jeder Statusänderung eine Info bekommt - und zwar genau eine. OK, zu einem Fehler ohne Statusänderung könnte man auch gerne 1 pro Stunde (so als Erinnerung) senden. Aber keinesfalls 100 in 2 Minuten zum gleichen Vorfall. :-)

GW Group keiner Firewall Rule zugeordnet habe, macht sie Failover.

Also nach meiner Logik macht sie dann gar nichts :D Denn wenn du sie nirgends einbaust, wird sie per se auch nix tun :) Wüsste nicht, dass das - außer für die GWGroup dann überhaupt irgend eine Rolle spielt. Wenn Leitung 1 wegfällt kann es schlicht deshalb sein, dass es kein GW1 mehr gibt und dann das Default GW automatisch GW2 ist. Ich wüsste jetzt nicht, dass da die GWGroup einen Anteil dran hat?

Aber anyway ;) Ja LB wird gemacht wenn man das Gateway zuweist. Deshalb ja auch 3 Gruppen für deinen Fall:

FO_WAN1 - GW1 T1, GW2 T2 FO_WAN2 - GW2 T1, GW1 T1 LB_WAN12 - FO_WAN1 T1, FO_WAN2 T1

um das mal so abzukürzen. Und damit sollte dein Szenario auch klappen.

Grüße

Alternativ zum Debugging: VPN Port auf was ganz Fremdes umstellen bzw. einen zweiten Server zum Test aufsetzen damit man hin und herschalten kann. Mir schwirrt auch noch was im Kopf rum, dass die Telejungs mal VPN gebremst/geblockt hatten in irgendeiner Situation, aber egal ob oder nicht, evtl hilft da schon ein anderer Port oder eben mal zum Test tcp/443.

Sorry, da muss ich meine 2 Cent dazuwerfen ;)

pfsense WAN (lass den DHCP Client am Besten an) –> Fritzbox
Fritzbox weist der pfSene eine IP...

Gruselig. Wenn man Router kaskadiert dann spielt man hier nicht mit DHCP. Das ist unnötig fehleranfällig und in dem Fall völlig egal ob es selten/kaum passieren kann oder nicht, es kann passieren und sollte daher schlichtweg vermieden werden. Es gibt kein Problem der pfSense schlicht auf dem WAN statisch die 192.168.178.2 zu verpassen und der FB zu sagen, dass ihr DHCP Bereich erst ab 10 oder 100 anfängt. Damit hat man alle Probleme vermieden und kann auch ohne Drama gleich den exposed Host auf die .2 setzen. Und ja ich hatte deshalb schon Drama weil eben nach einem Update der pfSense und Reboot die sense nicht mehr die .2 sondern die .3 von der FB bekommen hat. Und jetzt debugge man das Problem mal, wenn das ein Remote Standort ist. Ja sicher, mit MAC Reservierung wärs nicht passiert etc. etc. - doch, weil der Kunde auch gern mal schnell die ganze Box vor Ort austauscht (pfSense) - da wird dann zuerst Update auf neuer Box + Konfig eingespielt und dann die Box einfach schnell rundgetauscht. Dann müsste er jedes Mal wieder auf der Fritzbox das Mapping ändern...

Auf der FB das static mapping zu konfigurieren geht genauso schnell wie DHCP Bereich ändern, exposed Host muss eh eingerichtet werden. Die pfSense kann aber wesentlich schneller booten und ist im Fehler/Down-Fall der Fritzbox trotzdem sofort da und hängt nicht in einem unnötigen Interface DHCP Timeout herum bis sie weiterbootet weil sie keine Adresse bekommt. Ich verstehe hier wirklich komplett den Sinn nicht, warum man unbedingt auf der pfSense WAN Seite DHCP haben will, wenn das "WAN" im eigenen Haus steht und eine private Adresse hat. Das ist einfach unnötig fehleranfällig. ;)

Variante b) selektives weiterleiten, z.B. 443 für VPN
Vorteil: "sicherer"

Sehe ich nicht so. Sicherer ist es nicht, da - wenn eh alles über die pfSense läuft (was meist der Fall ist außer SIP/VoIP) - man auch dort alles managen möchte. Auf der FB ohne wirklichen Paketfilter und outbound Filter irgendwas debuggen ist übel. Zudem will man ggf. sehen, was da alles von außen kommt etc. Nur Port Fowardings für einzelne Ports ist meist fehleranfällig weil zu oft an zwei Stellen ständig nachgesucht werden muss warum irgendwas nicht geht. :)

Deshalb: 2 Handgriffe an der Fritzbox im Gegensatz zu ihrer Werkseinstellung: DHCP Bereich, exposed Host. Fertig. Sonst nichts angefasst. Und dann kann das Ding im Schrank vor sich hin oxidieren. Alles andere managed man auf der pfSense und hat seine Ruhe und muss weder mit dem Kabelbetreiber noch der Box noch großartig herumkaspern. Und zudem kann UM oder sonstwer problemlos einfach die FB mal austauschen. Kommt eine neue, einfach anschließen und anklemmen - selbst ohne die beiden Handgriffe hat man trotzdem SOFORT wieder Internet (da die .2 ja so oder so stimmt und andere Clients noch nicht herumschwirren) nach außen. Dann die 2 Handgriffe und auch von außen kommend klappt alles wieder. Schneller gehts nicht.

Als Zuckerguss könntest du das Natting in der pfSense ausschalten (Stichwort: doppel-Nat).

Den Satz verkneif ich mir. Ich kann das Double-NAT bashing nicht mehr lesen... Double NAT bringt euch an der Stelle überhaupt kein Problem außer bei VoIP und das kann/darf man durchaus vornedran packen an die FB, die vom Kabelanbieter meist eh schon den Telefon Teil vorkonfiguriert bekommt. Vorteil: funktioniert, ist vom ISP so gewollt und man hat kein Support-Chaos weil man "nicht unterstützte Lösungen" o.ä. einsetzt. Bei allem anderen ist NAT kein Hindernis von irgendwas. Zudem bekommt somit auch kein Provider Einsicht in die dahintergeschalteten Netze. Und das hat nichts mit Paranoia zu tun, sondern schlicht mit: hat den ISP nicht zu kümmern.

Gruß

Da bleibt nach gegenwärtigem Stand m.W. nur manuelle Arbeit. Aber es wäre jetzt keine große Anstrengung den eh bereits integrierten NGinx nochmals parallel auf anderem Port o.ä. zu starten und eine entsprechende Mini-Seite auszuliefern. Das wäre an der Stelle eh zu empfehlen, da der System (webUI) nginx aus logistischen Gründen mit root läuft und das für einen normalen Webserver mehr als suboptimal ist. Daher wäre es sicherer eine zweite Instanz zu starten auf einem anderen Port oder einer anderen IP.

Vielleicht wird auch das VHost Package irgendwann wiederbelebt, allerdings - wie gesagt - würde ich ungern einen VHost auf dem System-Nginx laufen lassen, da der mit viel zu hohen Rechten läuft und das hat auf einer Firewall dann nichts zu suchen.

Gruß