Ja, um das Routing brauchst du dich da nicht zu kümmern. Doch musst du auf einem weiteren Interface selbst Firewall-Regeln hinzufügen, die den gewünschten Traffic erlauben. Am LAN ist ja ab Installation bereits eine Regel gesetzt, die alles erlaubt.

Kein Problem, an den LB hätte ich an der Stelle als Proxy Ersatz aber auch denken können :D

Wenn System neu aufgesetzt: DNS Resolver aufrufen Unten in der Rubrik Host Override einen Eintrag machen für (bspw. xyz.dyndns.org) – Host: xyz -- Domain: dyndns.org -- IP: deine_interne_IP_des_webservers Speichern DNS Resolver sicherheitshalber neu starten Am PC den DNS Namen testen (Eingabeaufforderung, Powershell, whatever): nslookup xyz.dyndns.org Sollte nun auf die interne Adresse, nicht auf die externe Adresse zeigen. Wenn nicht nutzt dein entsprechender PC nicht die pfSense als DNS Server, dann wird das ohne NAT Reflection schwierig. Profit.

@Parsec: das war die Methode über link local unicast die mir noch im Kopf herumgeschwirrt ist - danke dafür :) @pfadmin: na die Weisheit hab ich auch nicht gefressen :P Ansonsten geht eben Hetzner bei der Vergabe nicht davon aus, dass du da viele kleine Maschinen laufen lässt, sondern dass du eben eine dicke hast und dafür ist das v6 Prefix auch genug. Bzw. wird da eher nicht davon ausgegangen, dass du da ne Router VM vornedranbastelst. Daher sind die auch extrem zickig, das "schön" zu machen mit ordentlichen Netzen auf jeder Seite. Daher kann man das /64 entweder auf dem WAN auflegen oder ins LAN schieben lassen - indem man wie Parsec eben den link-local für das Routing mit Hetzner nutzt und das v6 Netz dann auf dem LAN konfiguriert. Bei v6 gibt es (für 99% der Fälle) keine extern/intern/privat/öffentlich Diskussion mehr. Alle Adressen die vergeben werden sind erstmal weltweit erreichbar außer es wird dediziert was anderes gesagt. Punkt. Es gibt kein NAT oder sonstiges Geschwurbel. Auf jedem Interface das v6 fähig ist, liegt ein v6 Netz auf und es wird ganz normal und sauber geroutet und sonst nix. Keine NAT Krücken, keine Forwardings, Mappings, Source- oder Destination NAT, Redirects oder sonstwas. Clean & Simple.

Ah my bad, ich meinte nicht den Ping, sondern die Response Zeit bei den DNS Fragen. Wenn ich da in der Diagnostic Seite schaue, waren die 9er ziemlich lahm ggü der Antwortzeit von den 8ern oder bspw. OpenDNS. Aber vielleicht war das auch zum Launch nur so. :)

Damit war unglücklich formuliert gemeint, dass das zweite WAN bei zugeteiltem Gateway via DHCP auch dieses als "sein Upstream Gateway" nimmt, wenn es Daten vom LAN o.ä. bekommt. Das kommt dadurch, dass das GW fest auf das physische/logische Interface gebunden wird. Zudem gibt es dann automatisch erstellte Reply-To Regeln, die Traffic von diesem Interface auch wieder über dieses zurückliefern :) Aber ja "default" an der Stelle war doof ausgedrückt.

Die einfachere Lösung: Erzeug eine Regel die Traffic nach !LAN-subnet zulässt. Wenn du mehrere lokale Netze hast: Erzeug ein alias welches alle deine Netze enthält. Wenn du eh nur private Adressen lokal verwendest kannst du auch ein RFC1918 alias erzeugen welches: 10/8, 172.16/12 und 192.168/16 enthält. Das gast Netz darf dann auf !RFC1918 zugreifen. In diesem Fall die Regel welche Zugriff auf die pfSense selbst (dns, dhcp, etc.) zulässt nicht vergessen.

Dazu müsste ich erstmal wissen, WAS an deinem Custom Eintrag nicht funktioniert hat ;) Alles was ich sehe ist: {USER}:{PASSWORD} https://*****/dns/custom/{HOSTNAME} User/Pass sieht mir in dem Kontext nach HTAccess Zugriffsbeschränkung. Wenn du die ***** rein machst, kann man natürlich nicht sagen, was es für ein Dienstleister ist o.ä., daher wird das schwer ohne etwas mehr Info. Ansonsten: Services / Dynamic DNS / Dynamic DNS Clients / Edit Service Type: Custom Interface to monitor: WAN Send updates from: WAN Verbose logging on Username: {USER} Password: {PASSWORD} Update URL: https://*****/dns/custom/{HOSTNAME} Je nachdem was beim manuellen Aufruf von https://*****/dns/custom/{HOSTNAME} ausgegeben wird, kann man ResultMatch noch mit einstellen, aber das wars.

Manchmal erscheint als source "filterlog", manchmal der korrekte Hostname (wenn bspw. der NGINX etwas loggt) Filterlog erscheint nur, wenn du den Paketfilter mitloggen lässt. Der loggt im Normalfall kein SYSLOG Format, deshalb ist dessen Format auch abweichend und BTW auch spezifiziert: https://doc.pfsense.org/index.php/Filter_Log_Format_for_pfSense_2.2 Der Firewall Filter macht IMHO auch nicht so wahnsinnig Sinn den roh in irgendeinen Logfilter zu werfen, sondern wenn ihn als extra Logfile schreiben zu lassen damit man ihn getrennt auswerten kann. Das ist auch relativ egal, ob es ein HA System ist - denn dort ist eh nur ein System aktiv und das andere sollte keine großartigen Logfilter Meldungen haben, da kein / minimaler Traffic darüber fließt. Zudem will man - wenn man Traffic auswertet - eh meist nicht pro System sondern gesammelt auswerten, um bspw. Gesamt-Traffic oder pass/blocks sinnvoll auszuwerten, und dann braucht man logischerweise auch die Daten von beiden Systemen für den Fall dass es ein Failover gab. :) Gruß

Macht er doch - ist doch oben zu sehen. @lobi: Warum hast du default GW Switching überhaupt drin? Das ist doch für den normalen Anwendungsfall überhaupt nicht nötig und relevant!? Die GW Gruppe ist dafür da, das hin- und her switching abzubilden. Und mit der hatte ich bei MultiWAN noch selten Probleme. Gruß

Moin, ich bin aus dem Norden von HH und habe gerade gestern meine neue Hardware bekommen für die erste PF. Ich habe auch einen Wilhem Tel / TelQuick Anschluss. Kann mir einer von euch mal posten welche Einstellungen ihr gemacht habt, damit das login klappt ? Eike

Ich habs gefunden… Ich hatte in meiner OpenVPN Serverkonfiguration ein falsches Subnetz angegeben. Ich hatte aus Versehen das local network in den Tunnel Settings mit 32-Bit Subnetz angegeben obwohl es ein 24-Bit Subnetz ist. Angepasst, OpenVPN Server neu gestartet, Ping klappt! @JeGr: Danke trotzdem!

gib mal als Filter (samaccountname=%{User-Name}) ein.

Bitte lies doch mal meinen LINK weiter als die ersten paar Wörter. Da steht doch ganz klar: 1: AutoConfigBackup (zu pfSense Portal Server) 2: Pull It 3: Push It Und bei 2 die komplette Erklärung WAS man tun muss, um die Backup Routine eben im Beispiel via WGET zu triggern als wenn du auf der Seite den Button anklickst. Oder bei 3 wie schon beschrieben, wie man einfachst via SSH o.ä. die Konfiguration runter pusht auf ein anderes System.

Nicht wirklich die Empfehlung, aber es ist am Einfachsten auszurollen, da schon komplett fertig konfiguriert. Das File steht allen Gold Subscribern automatisch im Portal zur Verfügung. Grüße

Danke das war wohl der letzte Stolperstein, jetzt muss ich morgen auf der Trace im Fremdrouter schauen lassen Vielen Dank für deine Unterstützung

@trixters: haben schon genug Leute gemacht, allerdings eben nicht mit Wildcards sondern mit einzelnen Zertifikaten. SSL Termination via Proxy (meistens HAproxy) oder Loadbalancer ist nichts Abgefahrenes :) Und bei einer halbwegs passablen Umsetzung ist da kein Wildcard notwendig. Seit LE richtig am Start ist brauchen wir überall, wo wir sonst mit Wildcards genutzt haben inzwischen auf einzelne Zertifikate umgestiegen ohne große Probleme. Darum der Kommentar von LE bzw. mir: Wildcards nur wo es nötig ist :)

was immer gerne vergessen wird ist das routing. wurde eingetragen, dass man das jeweils andere Netz über den Tunnel erreicht ? dann wird der Split-Tunnel gerne falsch definiert. das hat wenig mit dem eigentlichen Tunnel zu tun.

Richtig, aber das "Gateway" ist wie gesagt eigentlich (zumindest von dem wenigen was ich weiß von deiner Konfig) falsch. Richtig wären Routen zu setzen und ein Gateway anzulegen, über den dein Netz für die pfSense erreichbar ist. Aber beim Interface selbst wird auf einem LAN eigentlich kein GW benötigt.