ich habe hier einen USB-WLan Stick LogiLink WL0049A den würde ich gerne an meiner pfsense als zusätzliches WAN konfigurieren der sich dann mit einen anderen WLAN verbindet.

Dann mach das doch :) Die Konfiguration von WAN/LAN unterscheidet sich ja nur darin, dass du beim WAN ein Uplink Gateway für dieses Interface hast. Alles andere ist eine Routing-Frage, keine technische LAN/WAN/irgendwas Unterscheidung :)

@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.