Also das was 9fisi1 beschreibt wäre so aufzusetzen:

                :                       :                 : Telekom VDSL          : Telekom VDSL                 :                       :             .---+---.                .--+--.        WAN1 |  DSL  |     Modems     | DSL | WAN2             '---+---'                '--+--'                 |                       |        Ethernet |                       | PPPoE                 |                       |            .----+----.             .----+----.            | Router1 |    Router   | Router2 |            '----+----'             '----+----' 192.168.101.1/24 |                       | 192.168.102.1/24                 |      .---------.      |                 +------| pfSense |------+     192.168.101.2/24   '----+----'   192.168.102.2/24                             :                internes LAN : 10.0.0.1/24

Wichtig hier: hinter deine beiden VDSL Modems wie in der Grafik 2 kleine Router hängen. Die müssen jetzt nichts dolles können, es genügt, wenn sie eine Einstellung haben (außer dem VDSL , was sie natürlich beherrschen müssen), dass du sämtlichen Traffic an einen "dedicated Host" (oftmals falsch auch als DMZ Host bezeichnet) weiterleiten können, OHNE dass etwas gefiltert wird.

Die beiden Router 1 und 2 bekommen dann intern eine statische Adresse (192.168.101/102.1). DHCP wird IMMER abgeschaltet, Freunde. Das nur an der Stelle erwähnt, weil ich hier etwas gelesen habe von DHCP im Transfernetz. Nichts da! Es gibt nichts schlimmeres als wenn eine Firewall (pfSense) in solch einem Transfernetz-Setup auch noch ständig wechselnde externe Adressen hat. Dann kommt nie Ruhe rein. Sicher, es sollte keine Adresswechsel geben, aber für Debugging und Diagnose ist es tödlich. Zudem es schwierig wird, dem Router beizubringen, dass die dedicated Host IP ständig wechselt.

Der pfSense geben wir aus den beiden Transfernetzen die .2 als statische WAN1/2 Adresse. Eigentlich bräuchte es an der Stelle auch kein /24 Netz, ist aber meistens einfacher zu verstehen. Theoretisch würde ich ein /29 vorschlagen, das vergeudet am wenigsten Adressen und ermöglicht trotzdem noch, dass man sich in die Transfernetze mit dazusteckt (Laptop o.ä.) um Probleme zu suchen.

Anschließend werden der pfSense noch die Gateways zugewiesen (die .1er Adressen) und für jede Strecke eine Check-IP hinterlegt. Bspw. 8.8.8.8 für WAN1 und 8.8.4.4 über WAN2 (das sind die beiden Google public DNS Server, geht aber auch mit anderen. Es darf nur nicht die gleiche IP pro Interface sein).

Danach im Debugging Menü durchaus mal einen Ping nach draußen machen über das Interface WAN1 und WAN2. Beides geht? Perfekt, dann kann mit der Konfiguration der Regeln und/oder sonstigen Dienste weitergemacht werden.

Grüße

Wenn du auf das Block-Symbol klickst (javascript event) sollte aufpoppen, welche Regel und warum geblockt wird. Ein Zugriff auf Akamai oder sonst irgendwas wird nicht einfach nur wegen dem Ziel geblockt. Wenn, scheint mir das eher wegen TCP Flags, Fragmentation oder sonst einem Grund zu sein.

Grüße

Ah, verstehe. Doch damit habe ich bei NAS4Free wohl keine Chance, da es sich komplett aufhängt, nachdem ich die serielle Konsole aktiviert habe: Es ist auch über die WebGUI oder SSH nicht mehr erreichbar - das habe ich gelegentlich auch bei pfSense beoachtet.

Wenn ich mich recht entsinne, ist es unter FreeBSD wohl so, dass der Boot-Loader wohl immer 9600 baud sendet, während die Kernel- und Daemon-Meldungen dann wohl variabel einstellbar sind.

Gruß
Peter

Ahoi,

na das ist doch schön zu hören :D Wenn du die Sense jetzt noch als AD-aware 2nd DNS einsetzen magst, müsste hier unter Domain Overrides noch folgendes rein:

Domain: firmenname.local
IP: IP-Adresse des DCs (AD DNS)
Description: WasAuchImmerDirGenugInfoVerschafft ;)

Damit weiß der DNS Forwarder der Sense dann, dass er *.firmenname.local doch bitteschön an den DNS auf x.y.z.a weiterleiten soll und tut das normalerweise auch :)

Grüßend
Jens

OK, alles klar.

Dann werde ich das mal testen. Danke für die Hilfe !

Ich werde bei meinem ISP nachfragen, ob dies die DNS Server sind. Ansonsten öffne ich sicherlich keine Ports auf der WAN Seite. Und nein, ich habe nur 1 WAN Interface.

@Nachtfalke: Hyper-V ist Windows/MS Hypervisor. Ganz andere Baustelle und Funktionsweise als KVM. Deshalb der verlinkte Beitrag der sich gezielt auf Hyper-V bezieht.

@tpf:

Servus,

verzeiht mir die späte Rückmeldung, ich war urlauben  ;D

Urlaub ist wichtig :) und ich freue mich, dass die Begrifflichkeiten geklärt werden konnten. Mich würde interessieren, ob "schinkenimitat" schon seine VPN-Implementierung gewählt und mit der Installation begonnen hat. Nach Threaderöffnung ist er/sie sich nicht mehr gemeldet.

Peter

Sorry, ich war noch bei der 5501 im Kopf. Das war die letzte, die ich selbst bei Kunden verbaut hatte. Stimmt, die neue 6501 ist da ein Problem. Und leider hat der ATOM auch kein AES-NI.

Gruß Jens

Hallo :)

natürlich ist der 2. Server nach dem Failover erreichbar - du sitzt dann ja drauf ;)
Das Problem wird sein, dass beide CARP Nodes - um für den Failover auch OpenVPN ordentlich bedienen zu können - natürlich das gleiche Einwahlnetz bereitstellen und dementsprechend nicht an den anderen Knoten routen.

Sprich: Via OpenVPN bist du mit deinem Netz (10.0.0.x) verbunden und dazu in einem VPN Netz (10.0.99.x) eingeloggt. Die Adresse aus 10.0.99.x bekommst du nach VPN Einwahl. Soweit alles gut, der VPN Server routet natürlich auch alles von 10.0.99.x zurück über sein Tunnel Interface zu dir. Gleiches ist aber auch auf Knoten 2 eingerichtet. Kommt also nun was von 10.0.99.x bei Knoten 2 an, routet der das nicht an Knoten 1 zurück (wo du verbunden bist), sondern behält es, da es in seiner Konfiguration natürlich genauso eingerichtet und auf SEIN Tunnel Interface geroutet ist (weil CARP und gesynct).

Ich glaube wir hatten die Diskussion hier schon einmal und der einzige theoretische Weg war, dass man evtl. ein anderen VPN Netz (10.0.98.x) auf dem anderen Knoten konfiguriert und dann die beiden VPN Netze über Kreuz auf die jeweils gegenüberliegenden Knoten routet. Allerdings ist dann KEIN sauberer VPN Failover mehr drin, weil man nach der Übergabe von Knoten 1 auf Knoten 2 bei Ausfall nicht mehr die gleiche IP behalten kann und getrennt wird / neu verbunden wird. Somit würden auch alle Sessions abreißen etc.

Ergo nicht so schön.

Insofern die einfachste Lösung: Um Knoten 2 zu erreichen, einfach über ein anderes System in deinem Netz gehen und von dort aus die Verbindung herstellen. Sowas wird gern auch "Jumphost" genannt, weil man sich eine kleine Kiste im Zielnetz sucht, auf der man sich einloggen kann um von dort aus weiterzuverbinden, weil man dort sonst nicht hinkommt.

Grüßend
Jens

Das ändert aber alles nichts an der Tatsache, dass ich im OP keinen Adresskonflikt sehe, sondern lediglich eine IP die ihre MAC gewechselt hat, was je nach Netzkonfiguration völlig normal sein kann. Wo wird denn an welcher Stelle von wem was für ein Adresskonflikt angezeigt?

Grüßend
Jens

Hmm also in einem "kleinen" Setup mit WAN & LAN sollte das Szenario kein Problem sein, da nach dem Reboot einfach nach den Interfaces gefragt wird. Anschließend sollten die auch wieder gehen. Die config.xml aber vorher zu sichern (full backup) und zu editieren ist aber sicher auch eine gute Möglichkeit :)

Tja, das Log sagt nicht sehr viel über den Traffic aus …
Muss ich da irgendwo noch den LogLevel hochdrehen?

Nachdem der WINS nun einen Tag durchgelaufen ist, klappt es auch mit dem Ping an den NetBIOS-Namen ...
Jetzt fehlt eigetnlich nur noch das Erscheinen in der Netzwerkumgebung des jeweiligen Servers ...
Die ist weiterhin leer bis auf den Server am Standort ...
Ich könnte das Netzlaufwerk zwar nun via \NetBIOS-Name\Freigabename verbinden, aber interessieren würde mich schon, ob man das hinbekommt ...

Wahscheinlich müsste ich dazu auf dem zweiten Root-Server auch einen DC aufsetzen und diesen als neuen Standort im AD einbinden.

Im Endeffekt würde das ja sogar Sinn machen ;)

Ja, ich werde an dem Tablet ansetzen und dann ggfs. nochmal im englsichen Forum posten. Ich halte Euch auf dem Laufenden.

Hallo,

ich habe es selbst nicht realisiert, aber soweit ich weiss müsste folgendes gehen:

System –> User Manager --> Server
Dort kannst du die pfsense an das AD anbinden. Weiterhin legst du für diese Konfiguration einen Namen fest.

Im OpenVPN Konfigurationsmenü kannst du dann als Backend den oben zuvor genannten "Namen" auswählen.

Du kannst es auch damit probieren, einen RADIUS server auf der pfsense zu installieren, diesen ans AD anzubinden und bei der OpenVPN Konfiguration dann als Backende deinen RADIUS auszuwählen.

Hi Reiner,

Also in den Antworten steht auch, dass der Provider nur den externen Ping verhindern kann, aber nicht den Tunnel-internen ping…

Nun, der Tunnel steht und ein ping auf das Servernetz funktioniert.
Ein ping auf die Tunneladresse ist ja sowieso nur zum testen nötig, wenn man den Server erreicht, muss auch der Tunnel stehen, vorausgesetzt die Firewall ist nicht offen wie ein Scheunentor. ;-)
Na ja, wieder was dazugelernt.

Gruß Peter

Hi,

eine DMZ ist vor allem erstmal ein Konzept das du bei der pfsence duch Firewallregeln und ein eigenes Segment umsetzt.

Siehe http://de.wikipedia.org/wiki/Demilitarized_Zone

Beispiel WEB-Server und E-Mailserver sollen von Extern und Intern erreichbar sein.
Du schottest sie aber gegen dein Internes Netz ab um bei einem Einbruch dein Internes zu schützen.
Die direkte Anbindung an eure Fileserver untergräbt das allerdings.

Woraus schließt du denn, dass der Neustart initiert wird? Lassen die Logfiles den Schluss zu, dass der Neustart immer zur gleichen Zeit erfolgt? Wenn das geklärt ist - ich vermute, du hast das schon getan und nur nicht geschrieben - würde ich in der Cron-Konfigurationsdatei /etc/crontab nachschauen.

Peter

Ich weiß nicht, ob der Thread noch lebt. Da er mich thematisch interessiert und ich mich selbst gerade mit wachsender Begeisterung in Squid, SquidGurad, SquidAnalyser, ClamAV und SquidClamav einarbeite, klinke ich mich mal ein.

Ich verwende Squid im nicht-transparenten Modus, da ich die Möglichkeiten der benutzerbezogenen Protokollierung evaluiere. Das Filtern überlasse ich dabei vollständig SquidGuard. Um eine Domäne wie facebook.com vollständig zu blockieren reichen der Eintrag "facebook.com" in den Dateien "domains" und "urls" im Datenbankverzeichnis des SquidGuard. Ich habe dies mit einigen Domänen erfolgreich ausprobiert. Das domänenbezogene Blockieren erscheint mir einfacher als über IPs bei den pfSense-Regeln. Doch dafür muss man aber Squid und SquidGuard installieren. Squid selbst kann auch zum Filtern verwendet werden, doch das habe ich bislang nicht getestet.

Zum besseren Verständnis muss ich sagen, dass der Squid-Proxy bei mir nicht auf der pfSense-Maschine läuft (NanoBSD), sondern auf einem Linux-Server.

Ich muss zugeben, dass zwar das Filtern mittels SquidGuard gut funktioniert, doch habe ich noch immer eine gewisse Restunsicherheit, ob es mit der bisher gemachten einfachen Konfiguration vom SquidGuard auch wirklich wasserdicht funktioniert. Für Korrekturen oder Ergänzungen wäre ich daher dankbar.

Peter