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.

Ich hab mal in die Client Config "NOBIND" eingefügt. Dannach hat sich die Verbindung wieder aufgebaut. Mal sehen ob das hilft. Ich werde in jedem Fall die Logs mal prüfen.

Ohne die Config zu sehen ist das nur Raterei (Zaunpfahl …), aber hast Du bei 'Redirect info' einen URL mit Protokoll eingegeben und geht es evtl. ohne?

Und rein aus Interesse: Wie hast Du die Sperre genau umgesetzt?

Aus sicherer Quelle weiß ich dass Vodafone derzeit 800-1000% überbucht. Hat man Pech und es laden gerade einige im Segment, bricht es ein. Das machen aber in der Tat derzeit alle Kabelanbieter, leider.
Mit Docsis 3.1 kann sich das etwas bessern, das bleibt abzuwarten.

Hi JeGr,
@JeGr:

Das funktioniert auch alles wie erwartet, die Serverdienste, welche ich per NAT in PFSense freigegeben habe, sind aus dem Internet via IPV6 problemlos erreichbar.

Soweit ich das im Kopf hatte bezog sich das aber auf einzelne Adressen, nicht auf ganze Prefix Ranges oder?

Doch, offenbar schon.
Habe bei mir auf dem Server noch einen virtuellen Server am Laufen, beide sind sowohl via IPV4-NAT als auch per IPV6 aus dem Internet auf bestimmten Ports ansprechbar.

In der Fritzbox musste ich dafür nichts weiter machen, als die beiden von mir erwähnten Optionen beim Einrichten des Exposed Host anzuhaken.
In PFSense habe ich dann Aliase für beide Systeme angelegt, die auf die netzwerkinterne IPV4 und die geroutete IPV6-Adresse verweisen.
Dann habe ich noch Regeln für die Port Forwards eingerichtet, mit automatisch generierten Firewall Rules. In denen habe ich dann noch "Adress family" auf IPV4+IPV6 umgestellt, fertig.
Muss also in der Fritzbox gar nichts mehr konfigurieren, wenn ich einen Port öffnen möchte.

Nur müsste ich dann die Fritzbox als VOIP-Anlage hinter der PFSense betreiben und zusehen, dass ich SIP über NAT zum Laufen bekomme.

Jap, das wäre dann die einzige andere Variante, um die Routing/IP Geschichte sauber zu haben. Einen Tod muss man wohl leider sterben :/

Joa, alles klar!
Dann muss es wohl so sein :-)

Hast du zufällig eine Empfehlung für ein gutes VDSL-Modem? Gibt zwar einige Router, die sich als Bridge umkonfigurieren lassen. Am Liebsten wäre mir aber doch ein simples Teil ohne eigenes Webinterface etc., dass ich einfach an die WAN-Schnittstelle anschließen und alles Weitere (VLAN-Tag, Einwahl) in PFSense konfigurieren kann.
Kennst du sowas, oder ist mein Wunsch zu ausgefallen? :-P

Auf jeden Fall vielen Dank für deine Tipps, hat mir wirklich schon sehr weitergeholfen!

LG,
Robin

@mrsunfire:

Mein Log ist voll mit "dhcpleases Could not deliver signal HUP to process because its pidfile (/var/run/unbound.pid) does not exist, No such file or directory."
Der Fehler tritt dann auf, sobald ein Client via VLAN eine IP zieht.

Die unbound.pid existiert in der Tat nicht. Was sagt der Fehler aus? Ich habe sonst keine Probleme.