Eine Firewall-rule auf dem LAN-Interface und ein Eintrag unter Services>DNS Forwarder>Host Overrides der den Server Kirk auf die interne IP definiert löst das Problem insofern, als man den Server aus dem LAN mit seinem Namen (kirk) erreichen kann. Das reicht f meine Zwecke allemal.

Das wäre auch mein Vorschlag gewesen. Der DNS Forwarder ist für einen "kleinen" SplitDNS Ansatz eigentlich genau richtig. Notfalls kann man hier noch eine komplette lokale Domain als local resolution auswählen (so dass bspw. domain.lan für ein AD immer NUR lokal aufgelöst und nie weitergereicht wird).

Leider kann ich nicht feststellen ob der Traffic übers richtige Gateway geht.
Wie kann man das feststellen/prüfen ?

Eigentlich recht einfach über einen Traceroute von intern (am Besten IP only ohne DNS Auflösung) und dann nachsehen, ob der nächste oder übernächste HOP des Rechners dann das GW vom zugewiesenen Netz ist oder das DefaultGW. Allerdings: wenn draußen die richtige IP ankommt, wäre es höchst seltsam, wenn der Traffic übers falsche Gateway ginge, weil das bedeuten würde, dass die zugewiesenen Teilnetze auch über das normal per DHCP erhaltene DefaultGW geroutet werden. Das wäre seltsam konfiguriert (es sei denn das Default GW wäre auch eben über mehrere IPs erreichbar, nur warum dann die Scharade mit dem DHCP?)

Dann ist auch noch die Frage zu lösen welche Hardware f die pfsense (die dzt noch auf einem alten schrottrechner haust) nun ins Haus kommen soll.

Nun da gibts diverse Möglichkeiten, aber bis auf 2 Sachen würde ich mir kaum Sorgen machen:

WLAN Nagios?

zu 1) Es gibt einfach (noch) keine aktuellen WLAN Treiber für pfSense, die ordentlichen Standard und Durchsatz ermöglichen. Wir hoffen, dass das mit 2.2 besser wird, da dieser Branch dann auf FreeBSD 10 (statt 8.3) aufsetzen soll und sich da Treiber-mäßig doch viel getan hat. Aber in 8.3 gibt es eigentlich nichts, was 802.11n spricht, geschweige denn 11ac.
Mein Tipp an der Stelle ist da auch wirklich, WiFi machen zu lassen von Geräten die nichts anderes tun und den AP dann einfach an ein dediziertes Interface der pfSense zu hängen. Dann ist auch Captive Portal etc. nur ein kleines Problem. Und je nach AP kann man dann dabei gleich noch Nettigkeiten wie unterschiedliche VLANs, multiple SSIDs und Co implementieren

zu 2) Was willst du mit Nagios auf der pfSense? ;)

Aber was ich mir durchaus vorstellen könnte für deine Anforderungen: Die Lanner FW-7541D. Dazu kannst du auch hier im Forum den österreichischen Kollegen "esquire1968" aka Thomas befragen, der hat sich das gute Stück gerade zugelegt. Ich selbst habe den Vorgänger, eine FW-7535H. Was dafür spräche - und sich mit deinen Anforderungen deckt:

Dual Core Intel Atom D525 (genügt für die meisten, nicht so CPU lastigen Prozesse, wenn nicht noch extrem viel VPN dazu kommt etc.) 6 x GbE LAN ports (genug zum Spielen und für diverse Interfaces: 2x WAN, 1x DMZ, 1x LAN, 1xWLAN, 1x VOIP bspw.) Up to 4GB of RAM (damit kann man auch über eine kleine Snort-Lösung nachdenken) SATA and CompactFlash (somit CF Karte kein Problem, 2,5" SSD/HDD Einbau ist aber später auch kein Problem wenn man mehr Platz bräuchte) Mini-PCIe Expansion (wäre theoretisch für WiFi möglich, evtl. gibt es auch irgendwann mal wieder Crypto-Karten in dem Formfaktor für VPN speedup oder auch eine 3G Modemkarte) Lüfterlos Leise Sehr geringer Stromverbrauch

Ist mit ca. 480€ zwar auch nicht gerade "günstig", billig ist sie auf gar keinen Fall. Und eines der wenigen Geräte, die gleich mit stolzen 6 1GbE Interfaces daherkommen. Syslogging auf externen Host ist ja kein Problem, via SNMP und/oder NRPE/Zabbix Client lässt sich das gute Stück auch überwachen, ein paar OpenVPN Connects sind kein THema und deine WAN Bandbreite ist noch jenseits eines Werts, wo das gute Stück zu schwitzen anfangen würde (außer natürlich bei heftigem Snort Einsatz ;))

Grüße

Hallo,

ich würde ebenfalls versuchen, ersteinmal ein Basic Setup zu etablieren, bevor ich Dinge wie 2. LAN oder Portweiterleitungen am Speedport angehe.

Ein Ping in den Diagnostics von pfSense funktioniert? Also von .2 auf .1? Der Speedport wird erreicht? Wird im Dashboard auch das aktuelle Update angezeigt etc? Also hat die pfSense Netz etc.?

Wenn ja, dann gehts weiter:

Ich würde in den DNS Einstellungen der pfSense NICHT den Speedport angeben. Das kann gehen, muss aber nicht. Ich würde testweise bspw. 8.8.8.8 und 8.8.4.4 nehmen (Google DNS) oder welche vom OpenNIC Projekt. Damit sollte die pfSense auf jeden Fall DNS können und auch Netz haben. Unter Diagnostics müsste also bspw. ein ping auf www.test.de gehen (Namensauflösung plus Ping)

Zweiter wichtiger Streich ist auf dem WAN Interface den Block der private Adresses rauszunehmen. Auf dem LAN ist das klar, aber da du ein Transfernetz zum Telekom Router machst, wichtig. Hast du aber wohl schon angehakt, trotzdem bitte checken dass es auch am WAN, nicht nur am LAN aus ist.

Gateway auf dem WAN ist gut! Bitte auf dem LAN KEIN(!) Gateway eintragen. Das LAN soll ja nicht woandershin geroutet werden, sondern die Default-Route ins Internet nehmen. Ein Gateway hier wäre kontraproduktiv. Also LAN auf "kein" stellen. Unter System/Routing/Gateways sollte es nur ein (und default) Gateway geben, die .1 aus dem WAN Netz.

Außerdem keine anderen Routen

DHCP alle Reiter gegenchecken ob abgeschaltet, dann bitte den Dienst ggf. stoppen. Auch den DHCP6 Dienst nicht vergessen, damit Windows nicht durcheinander kommt.

Wie gesagt Weiterleitungen oder derlei kram am Speedport erstmal unterlassen, das ist nicht wichtig. Der Speedport sollte standardmäßig NAT machen für das .1.x Netz.

In Firewall/NAT/Outbound auf Manual umschalten und speichern. Das sollte 1-3 Regeln erstellen, die für eine outbound NAT von LAN->WAN zuständig sind. Im Normalfall sowas wie:

WAN 192.168.10.0/24 * * * WAN address * NO/YES <beschreibung>8) DNS Forwarder: Für alle Interfaces aktivieren, sollte per default eigentlich schon gut funktionieren.

Das zweite LAN etc. erstmal abschalten/löschen/disablen, damit das nicht reinspielt

Wenn das soweit fertig ist, bitte den Testclient auf irgendeine 192.168.10.x Adresse konfigurieren, Default GW ist dann die .10.1, DNS ebenfalls 10.1 und dann mal schauen ob der Browser browst.

Ggf. einen Ping auf .10.1 und www.test.de (oder irgendwas anderes Öffentliches), sollte aber sinnvollerweise ein Dienst sein, der auch antwortet ;)

Wenn das soweit läuft, kann man denke ich weitermachen. Eigentlich sieht dein Trace schon so aus als würde dein Internet funktionieren, aber einfach die Liste nochmal checken. Ansonten prüfst du Sachen die relativ irrelevant sind oder gar nicht funktionieren können ;)

Bspw.: ARP Adressen sind meist IMMER dynamisch. Das heißt nur, dass sie discovered werden bei Bedarf aber auch aus der Liste wieder gelöscht werden können. Statische Einträge sind immer da.  Bestimmte Multicast Adressen und natürlich auch der Broadcast sind natürlich statisch (die müssen ja da sein), die pfSense ist statisch -> machst du sie aus, wird sie aus der ARP table nach gewisser Zeit gelöscht. Vollkommen richtig. Bitte hier nicht ARP und IP durcheinander würfeln, dynamisch bei ARP hat nichts mit dynamic IP zu tun.

192.168.10.1 - dynamisch (korrekt)
192.168.10.255 - statisch (korrekt - Broadcast)
224.0.0.22 - statisch (korrekt - IP multicast)
224.0.0.252 - statisch (dito)
239.256.255.250 - statisch (dito)

Siehe: https://social.technet.microsoft.com/Forums/windowsserver/en-US/98f6bbcb-38f6-4e88-ad43-181377111140/why-some-default-entries-in-windows-arp-cache-are-of-static-type-

Desweiteren ein Denkfehler:

"Ein Ping ueber die Eingabeaufforderung am Client zu 192.168.1.2 und 192.168.10.1 geht, 192.168.1.1 nicht.
Ein Ping ueber Diagnostics im PFSense erreicht alle IP Adressen."

Die Firewall kennt alle Netze, kann ergo auch alle anpingen. Dein Client kennt nur sein eigenes .10.x Netz. Er schickt sein Paket an die pfSense, welche es an die .1.1 weiterleitet. Der Telekomrouter hat aber keiner Ahnung, dass hinter .1.2 (pfSense) noch ein weiteres Netz hängt und würde es daher an das Internet weiterschicken (sein default GW). Da das aber per Routing Definition von private IP ranges verboten ist, wird das Paket verworfen. Es findet quasi seinen Rückweg nicht.

Ich kenne die SPeedports nicht, aber bei guten Routern oder bspw. einer Fritzbox kann man zusätzlich Routen einpflegen. Dort könnte man - wenn man muss - bspw. die Route 192.168.10.0/24 eintragen mit GW auf die .1.2, damit der Speedport alle Pakete vom LAN auch wieder an die pfSense beantwortet. Ist aber m.E. überflüssig, da man nur selten vom LAN direkt auf den Speedport muss.

Ansonsten besteht glaube ich deine Schwierigkeit nur noch darin, das 2. LAN flott zu bekommen und dem Speedport Portforwarding auf die pfSense beizubringen.
Ich würde sogar so weit gehen, dass ich (wenn er das kann), dem Speedport sagen würde, er soll ALLES auf die pfSense weiterleiten (exposed Host oder manchmal auch fälschlich DMZ Host genannt).

Hoffe das hilft dir erstmal weiter :)

Grüße</beschreibung>

Hi!

Deine Anmerkung mit dem Tunnel war goldrichtig - jetzt klappt die Verbindung.

Ich hatte tatsächlich "nur" eine Client to Server Verbindung aufgebaut, benötige aber eine LAN <> LAN Verbindung.

Die Konfiguration des Tunnels war mit dieser Anleitung dann einfach …

http://www.google.at/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=1&cad=rja&ved=0CC0QFjAA&url=http%3A%2F%2Fdoc.pfsense.org%2FCreate-OpenVPN-client-to-TUVPNcom.pdf&ei=F2tYUsnHL4Oo4gTHwoHADw&usg=AFQjCNE-cDMMbGObaYTD2EGUGxbXQlVIoA

Nochmals vielen, vielen Dank!

Gruß
Thomas

Das Squid Paket ist die latest 2.7er Version von Squid, Squid3 bezieht sich auf die 3.1.x Version. Squid3-devel bezieht sich auf den aktuellsten 3.3.x snapshot von Squid. Ersteres ist stable, squid3 als beta geflagged (aber ich würde es als recht stabil einschätzen) und die latest Version ist für alle die ggf. ein besonderes Feature aus der Development Version benötigen. Wichtig ist nur, dass andere Pakete für die richtige Squid Version installiert werden, sofern benötigt (wie squidguard o.ä.).

Welche du benötigst, liest du am Besten am Feature Set im Squid Wiki, da 2.x und 3.x parallele Releases sind, 2.7 aber wohl die letzte 2er Version ist, trotzdem die 3.x aber noch nicht alle Funktionen aus 2.7 übernommen hat:

http://wiki.squid-cache.org/Squid-2.7
http://wiki.squid-cache.org/Squid-3.0

Ich würde vermuten, 3.1 oder 3.3 wäre das was du suchst, aber das ist nur eine Vermutung.

Vielleicht kannst du auch mal in die Datei zabbix2-proxy.xml reinsehen (die Konfiguration des Pakets), evtl findest du dort die Parameter die deine Einstellungen überschreiben.

Grüße

Ich musste alles von Hand deinstallieren und wieder installieren.
Mit der automatischen neuinstallation der Packages die pfSense beim Update durchführt hat es nicht funktioniert..

Frag mich nicht wieso..

Aber ich musste Squid, Squidguard und Sarg manuell deinstallieren und neu installieren damit es lief..

Hi,

natürlich wäre es schön wenn du uns hier auf dem Laufenden halten kannst - sofern es natürlich keine zu detaillierten Infos sind, die ggf. vitale Daten enthalten. Die natürlich weglassen ;)
Ich bin gerade im Zuge einer Neustrukturierung/Umstellung und löse damit ein 2-Knoten Juniper-Firewall-Cluster ab. Das ist momentan auch viel Arbeit, da nach der Re-strukturierung relativ viele kleine VLANs vorhanden sein werden. Und die müssen eben alle als eigenes Interface aufgelegt und konfiguriert werden. Zweifach. Das ist lästig, aber damit kann man die einzelnen VLANs auch wesentlich besser separieren und gegeneinander absichern. Da ich (hoffentlich) wenig Intra-VLAN Kommunikation habe, sondern das meiste nur von Projekt-VLANs zu einem Infrastruktur VLAN (DNS, Mail etc.) und der Rest Traffic ins Internet ist, hoffe ich, dass die Last der FW hier gering genug ist. Ansonsten steht immer noch die Möglichkeit offen, die VLANs auf Switche hinter die Firewall zu verlagern und die Switche mit einem großen Transfernetz anzubinden. Das bringt dann aber wieder Komplexität ins Setup, denn dann muss ggf. nicht nur die Firewall gecheckt werden (bei Problemen), sondern auch die Switche, dort ggf. noch Regeln etc. etc. deshalb ist unser Plan bislang, das meiste auf den Firewalls zu terminieren und einige High-Traffic VLANs, die eh kein Internet brauchen (Backend, Management, Backup-Netze) direkt über die Switche abzubilden und damit den Traffic von der Firewall fern zu halten. Ob das klappt - weiß ich in einigen Wochen ;)

Grüße

Bis auf die Punkte mit Snort und IDS arbeiten so unsere DC-pfSensen auch. Das Setup ist also recht einfach zu realisieren. Da ich selbst Snort und Co noch nicht am Laufen habe, kann ich leider nichts dazu einstreuen, du solltest aber darauf achten, genug CPU und RAM Power übrig zu haben, da m.E.n. Snort recht RAM-lastig werden kann.

Viele Grüße

Wenn du kurz ein paar Zeilen dazu schreiben könntest, wäre das sicherlich hilfreich. Dann muss nicht erst nachgefragt werden, wie du das gelöst hast :)

Von meiner Warte aus würde ich sagen - sofern dein Diagramm stimmt - dass du da ein paar kleine Fehler drin hast, denn die LAN/DMZ Netze sollten überhaupt nicht mehr bei der Fritzbox ankommen, aber vielleicht ist das auch irreführend gezeichnet, da du pfSense und Alix einzeln einzeichnest?

Im Prinzip wäre das Vorgehen sehr einfach zu lösen:

Fritzbox bekommt nicht mehr die beiden .1er und .2er Netze, sondern nur noch eine IP aus einem "Transfernetz" zum WAN Port der ALIX zugewiesen. Bspw. FB: 192.168.168.1, AlixWAN: 192.168.168.2. Die Alix bekommt als Default GW die FB (192.168.168.1) In der FB wird eine komplette Weiterleitung aller eingehenden Pakete aktiviert auf die IP der AlixWAN: 192.168.168.2 Die beiden anderen Interfaces der ALIX (LAN, OPT1) werden für dein .1.x und .2.x Netz vorbereitet, die ALIX bekommt im jeweiligen Netz die .1 und ist das GW des Netzes (LAN/DMZ). Regeln anlegen auf LAN/DMZ damit LAN->DMZ und DMZ->LAN reden dürfen (sofern gewünscht) Outbound NAT der pfSense auf Advanced umschalten (damit die LAN Regel erzeugt und agezeigt wird). Die LAN Regel 1:1 für das DMZ Interface kopieren, damit LAN und DMZ Internet haben. Fertig, DMZ und LAN sollten Internet haben. Wird nun ein Portforwarding benötigt in die DMZ bspw., wird diese ganz normal auf der pfSense eingerichtet, da die FB einfach alles was hereinkommt komplett an die Alix weiterleitet.

Läuft so bspw. hinter einer Kabel-FB oder auch einer DSL FB ohne Probleme. Die FB kann sogar selbst noch aus dem INet erreichbar gemacht werden (auf einem alternativem Port, da der SSL Port 443 von mir bspw. für OpenVPN oder für Management der pfsense genutzt wird) ohne dass es mit dem Restlichen NAT, PortForwarding oder sonstigem ein Problem gibt.

Kommt leider etwas spät sorry ;)

Grüße

Hallo JeGr,

wenn mein DSL Anschluß ausfällt soll der Stick die Verbindung zum rest der Welt halten.
Das funktioniert sogar schon sehr gut. Sobald ich das Modem Kabel aus der pfsense ziehe bin ich halt über 3G Online.

MfG
kaschuppke

Hallo,

nach weiterem Probieren musste ich feststellen, dass dieses Problem von einem openVPN Client Tunnel ausgelöst wurde, nach abschalten von diesem klappte alles wieder.

Hallo Corny,

das "user" hat an der Stelle nicht direkt die Bedeutung eines "Users", sondern bezieht sich eher darauf, dass die CPU tatsächlich etwas mit Prozessen aus dem Userspace zu tun hat und weder mit Interrupt Handling, noch Kernel Threads (system) oder (de)priorisierten (nice) Prozessen zu tun hat. Da auf der pfSense annähernd jeder Service als "root" läuft, würde die Anzeige also nichts bringen - er würde dir lediglich sagen, dass ca. 95% der Last durch "user" durch "root" erzeugt wird ;)

Wenn du dir ansehen willst, welcher Prozess wirklich die CPU stresst, solltest du das besser mit bspw. 'top' erledigen. Entweder auf der Konsole oder via GUI.

Grüße

Unterstützt wird PFS schon länger (ich glaube mich an 2.0 zu entsinnen). Wenn die Option ausgegraut ist, dass ist sie in dieser Kombination einfach nicht wählbar. Sprich sehr wahrscheinlich sind vorher Einstellungen gesetzt, die diese Schalter verhindern.

Ansonsten hilft bei der Einrichtung vllt. http://blog.benca.net/2012/03/05/serving-ipsec-vpn-with-pfsense/
Allerdings - sieht man auch im Blog Eintrag - kann PFS und Co. unter anderem die Android Kompatibilität brechen.

Grüße

@JeGr:

@MgT Bei einer HD Installation ist es durchaus möglich, dass die pflogs gespeichert werden. Aber Nachtfalke hat recht, was embedded Systeme angeht, die werden meist nicht gespeichert sondern sind flüchtig.

stimmt, sorry, daran habe ich gar nicht gedacht.

Hallo MgT,

auch ich wollte mich an dieser Stelle für die super Tutorials / Videos von Dir bedanken!
Würde mich auch über weitere, neue Video-Tutorials freuen.  ;)

Viele Grüße!

sorry für die verspätete Antwort. Hatte noch ein paar wichtigere Sachen um die Ohren.

Um hier das Problem als gelöst zu markieren hier die Antwort:
In dem Modem von DLINK (DSL-321B) muss der Zugang nicht auf PPPoe stehen, sondern auf BRIGDED-Modus
Dann kann man in der PFsense die Verbindung per PPPoe einrichten und das klappt sofort.

Danke trotzdem fürs mitdenken.

Hab eine Lösung gefunden. :)

Backup vom CaptivePortal erstellen.

Folgende Zeilen fehlten im alten Backup:

<captiveportal><test>Test <zoneid>8000</zoneid> . . .</test></captiveportal>

Diese einfügen, abspeichern und das Backup wiederhrstellen.

Kann jemand erklären was die Zoneid bedeutet? Diese lag beim Anlegen eines neuen CaptivPortal bei 8000.

Grüße
Schwabe

Also Server habe ich mal getauscht leider bleibt das Problem weiter bestehen.
Noch Ideen?