hallo Fireball1234, zur ersten Frage: Sobald du die Richtlinien änderst, werden ALLE bereits generierten Rollen ungültig! Ob das aber mit dem Systemabsturz zusammenhängt ist ungewiss. Was meinst du mit fährt nicht mehr hoch? Nach dem du das Ding vom Netz getrennt hast?

Der Zugriff auf die http-Config des/dieser Clients funktioniert innerhalb des Remotenetzes wunderbar. Und tatsächlich sind es zwei Clients die erreicht werden sollen. Sie verwenden unterschiedliche Ports für http, kommen sich also nicht gegenseitig in die Quere.

@TheFragger: Die pfSense kann diverse Versionsschritte rückwärts. Zu finden unter Diagnostics / Backup&Restore und dort im Tab Config History. Dort hätte man entsprechend auf einen alten Stand zurückrollen können, in dem User/Zert noch vorhanden war :) Grüße

Tor habe ich bisher nicht genutzt und kann dir dadurch in diesem Punkt nicht weiterhelfen. Ich nutze VPN um z.B das ganze Angebot von Netflix auf einem Chromecast oder ähnlichem nutzen zu können, da ist der Anbieter relativ egal.

Aufgrund von möglichen Wenn und aber muss man dazu sagen, dass eine seperate Leitung dir sehrwohl einen Gewinn an Sicherheit bringt, wenn das ganze nicht an dem Switch mit dem Privaten und Gäste VLAN zusammenhängt. Es wurde oft genug gezeigt, dass entweder ein falsch konfigurierter Switch oder sonstiges bugs/exploits die Möglichkeit boten um VLAN-hopping, VLAN-Trunking etc. zu begehen. Somit ist es eben oftmals doch sinnvoll eine DMZ auf einem seperaten physischem Interface zu terminieren. Ob diese Situation auch auf ein Home-Setup trifft, muss jeder für sich selber entscheiden da dies oft mit mehr Kosten verbunden ist.

Wow, danke für den Hinweis. Ich versuch mal nen Update.

Hi zusammen, seit knapp 2 Wochen ist mir aufgefallen das die Pfsense anzeigt das auf beiden Internetleitungen Paketverluste stattfinden. Wir nutzen beide Leitungen mit Loadbalancing und beide Leitungen sind von der Telekom. und was hat sich bei der telekom geändert? Wie viele Kunden sind neu dazu gekommen mit denen Du Dir jetzt den völlig überbuchten Router auf der Telekomseite teilen musst? Wan 1 - 14% Paketverluste  - Fritzbox VDSL 50 Wan 2 - 10% Paketverluste  - Telekom Hybdrid 50 Und was ist davon noch übrig wenn man eine doppel-NAT Situation hat? Normalerweise verliert man dadurch nur 3% - 5% an Durchsatz aber alles andere funktioniert dann eben auch richtig. Schon mal versucht? Das seltsame ist das es immer funktioniert sprich 0% Paketverluste anzeigte. Seit 2 Wochen besteht das Problem. Es wurden auch keine Änderungen in der Zeit durchgeführt. Telekom hat auch die Leitungen geprüft und sagt das alles in Ordnung sei. Das bringt nur leider sehr wenig wenn die Telekom viele neue Kunden bei Euch angeworben hat und eben nicht auch gleich noch neue Router angeschafft hat, auf die sie diese neuen Kunden verteilt hat. Hat jemand einen Vorschlag? Sind die IP Adressen statisch an den WAN Ports oder via DHCP von den Routern? Mal mit WireShark mitgesnifft an den Routern vor der pfSense, was da los ist? Ist an den Routern DHCP aktiv oder deaktiviert worden? Was wird denn für das Load Balancing benutzt? Policy based Routing Service based Routing Session based Routing

Bedankt!

Da ich für das öffentliche Wlan und den Proxy den Netzwerkverkehr loggen möchte, wäre eine mSATA wohl die beste Wahl. Ich werde mir in den nächsten Tagen eine APU.1D4 bestellen und dann nochmal Rückmeldung geben. Da aktuell bei mir noch unmanaged Switches eingesetzt werden, ist noch tagged und untagged Netzwerkverkehr gemischt. Habt Ihr hier Empfehlungen für Switche die nicht allzu sehr kosten. Benötigt würde ein 8 Port Switch  der Vlan fähig ist, optional mit LACP und MAC based authentication / 802.1X.

Hallo OK, ich werde es mal versuchen, die comfig.xml rüberzuspielen, wenn sich was ergibt, schreibe ich es euch mal danke und schönen tag Thomas

…oder WAN und DMZ haben tatsächlich den gleichen Netzbereich bekommen, was auch nicht gut wäre.

Dein Problem wird sein, dass das Gateway der entfernten pfSense auf deren WAN Schnittstelle eingetragen ist. Sie hat also kein Gateway, über das sie Dich remote erreichen kann. Lokal in der Broadcast-Domain funktioniert das selbstverständlich, dafür wird kein Gateway benötigt.

Hallo Zusammen Ahh Carp IP sind nicht gleich WAN addresse, wieder was gelernt. Habe jetzt die Regel auf WANnet gestellt und alles funktioniert  :) Danke JeGr Jetzt habe ich einen Failover für die physischen pfsense Firwalls. Wenn mir aber der ISP temporär den Dienst kündigt würde mir das nicht helfen. Daher habe ich jetzt auf der Firewall 1 einen weiteren Port aktiviert. WAN2: 172.16.0.100 / 16 mit dem passenden Gateway. Die DNS wurden auch angepasst 8.8.8.8 = GW1 8.8.4.4 = GW2 Gateway Group erstellt WAN1: Tier 1 WAN2: Tier 2 Trigger Level auf Member Down Die Überlegung auf Member Down ist das es der 2. ISP mir eine sehr kleine Leitung gegeben hat und ich wegen einem fehlenden Paket nicht alles gleich auf den 2. ISP switchen will…daher "Member down" (Notbetrieb) Das sollte mir einen Failover für den ISP geben oder? Habe Test-halber einen ping auf 8.8.8.8 gesetzt und das Kabel von WAN1 gezogen und der Client hat nach einem fehlenden ping wieder fröhlich an weiter gepingt  ;D Gruss DarkMasta edit: Kann es sein das noch zusätzliche Firewall Rules auf diese neue Gateway Group zielen müssen?

@benjsing: Mein normales Netz ist 192.154.13.1 Nein, DAS ist nur eine IP und kein Netz (es fehlt dazu die Netzmaske). Zudem noch eine public IP, das ist so korrekt?

Hi, ich weiß leider auswendig nicht, wo diese CDF Files hingeschrieben werden, würde aber vermuten, dass diese irgendwo unter /var geschrieben werden, was bei einer Nano/CF Installation ja die Ramdisk ist, und somit den Neustart nicht überlebt. Das wäre zumindest mein Gedanke. Müsste man mal suchen, wo die im Betrieb abgelegt werden, und ob man den Ort via Advanced Settings überschreiben kann. Viele Grüße

@bon-go: Was die VPNs angeht, stimme ich teils zu. Schneller aufbauen o.ä. sehe ich da zwar nicht (das hängt immer an der Konfiguration), aber der Durchsatz, wenn du volle Leistung von synchron 100MBit/s oder 1Gbit/s brauchen würdest, wäre sehr wahrscheinlich schneller, dank AES-GCM. Da sich hier aber auch auf OpenSSL/-VPN Seite einiges tut, sehe ich das zukünftig eher auf Augenhöhe. Was "Einfachheit" der Konfiguration angeht, sehe ich allerdings OpenVPN eher vorne. Gerade wenn man nicht nur Clients anbindet (was meistens einfacher ist), sondern ganze Netze und nicht beide Endpunkte kontrolliert (Gerät der Gegenseite != pfSense) kann das echt fies werden mit IPSec. Hatte deshalb viel auf Konferenzen oder Versammlungen bei Netzwerk oder auch IPv6 Vorträgen gehört, die lieber OpenVPN nutzen als IPSec, auch weil dann Dinge wie Policy Based Routing einfacher zu realisieren sind. :)

dies…. [image: Aufnahme10.jpg] [image: Aufnahme10.jpg_thumb] [image: Aufnahme11.jpg] [image: Aufnahme11.jpg_thumb]

Ja, genau das fehlte offensichtlich - vielen herzlichen Dank! Zuordnung nun: *** Welcome to pfSense 2.2.5-RELEASE-pfSense (amd64) on pfsense *** WAN (wan)      -> pppoe0    -> v4/PPPoE: <xxx>/32 VPN (lan)      -> ovpns2    -> v4: 172.16.17.1/32 VLAN13 (opt1)  -> lagg0_vlan13 -> v4: 172.16.13.1/24 VLAN11 (opt2)  -> lagg0_vlan11 -> v4: 172.16.11.1/24 VLAN12 (opt3)  -> lagg0_vlan12 -> v4: 172.16.12.1/24 VLAN14 (opt4)  -> lagg0_vlan14 -> v4: 172.16.14.1/24 VLAN10 (opt5)  -> lagg0_vlan10 -> v4: 172.16.10.1/24 VLAN16 (opt6)  -> lagg0_vlan16 -> v4: 172.16.16.1/24 VLAN15 (opt7)  -> lagg0_vlan15 -> v4: 172.16.15.1/24 VLAN18 (opt8)  -> lagg0_vlan18 -> v4: 172.16.18.1/24 VLAN19 (opt9)  -> lagg0_vlan19 -> v4: 172.16.19.1/24 VLAN20 (opt10)  -> lagg0_vlan20 -> v4: 172.16.20.1/24 VLAN21 (opt11)  -> lagg0_vlan21 -> v4: 172.16.21.1/24 PIAVPN (opt12)  -> ovpnc4    -> v4: 10.101.0.34/32</xxx>

@BlueKobold: Wenn hier explizit nach einem Dienstleister gefragt wird, weil es eben jemand NICHT selbst machen will, dann ist das für mein Empfinden völlig in Ordnung. Und er hat ja durchaus einige Angebote bzw. Nachfragen bekommen, sich allerdings bis dato nirgends gemeldet (zumindest hier im Forum o.ä.). Ruhig Blut.