@benjaminmb Wenn beide Anwendungen auf demselben Server laufen, kann doch gleich dieser die Differenzierung anhand des Hostheaders machen. Allerdings musst du jedem virtuellen Server ein zum Hostnamen passendes Zertifikat zuweisen, was ohnehin Voraussetzung ist, damit TLS problemlos funktioniert. Dann kannst du auf der pfSense https einfach weiterleiten und benötigst keinen Port zum Aufrufen.

Problem gelöst! danke @JeGr für den Hinweis. Ich habe in den Auto-Rules immer das Interface eingetragen. Mit dem Standardwert, einem Port-Alias der 3cx-Ports und den empf. NAT Einstellungen läuft es nun.

Die Agfeo nutzt Port 5060 für die externe Kommunikation, die SIP-Konten bekommen aber einen eigenen Port von der Anlage. Ein Packet im internen Netz sieht wie folgt aus: [image: 1631458968995-8ab6778e-d345-40dd-993d-c1e778968a5d-grafik.png] Kann es sein, dass ich hier noch etwas umstellen muss?

@callya Ah das geht natürlich auch. Normalerweise hat man im Default GW dann die Route zum VPN Server drin damit der es weiterrouten kann. In deinem Setup wäre dann aber asymmetrisches Routing entstanden was sich mehrfach mies auswirken kann. Man kann aber natürlich auch auf den Clients das GW eintragen, dann senden die es direkt dahin. Ist aber in den meisten Fällen zu viel Arbeit weil jeder Client angefasst werden muss. Alternative dazu noch möglich: via DHCP eine zusätzliche Route pushen, hängt dann aber vom GW ab, ob das diese Möglichkeit hat. Das müsste - wenn man das mit der pfSense machen wollen würde - die DHCP Option 121 sein wenn ich recht entsinne. Ist dann nur etwas "Gefriemel", da man DHCP Option 121 als "string" konfigurieren muss und da nicht einfach IP Netz und Maske reinklöppeln kann. FYI: Wenn man DHCP Option 121 manuell konfigurieren möchte, muss das Format des Strings in pfSense so aussehen: 0xMMZZZZZZZZGGGGGGGG Wobei die Buchstaben als Platzhalter stehen für: M = Subnetz Maske in CIDR Notation in Hexadezimal, also /24 -> 18 Z = Zielnetz in Hexadezimal 172.16.1.0 -> AC100100 G = Gateway über den geroutet wird in Hex 192.168.1.254 -> C0A801FE das wird zusammengesetzt nach RFC 3442, was heißt, dass die unnötigen Bits weggelassen werden müssen (kompakte Schreibweise). Somit: Für 172.16.1.0/24 via 192.168.1.254: DHCP Option 121: 18:AC:10:01:C0:A8:01:FE Man kann natürlich auch mehrere Routen angeben, die werden dann einfach aneinander gehängt. Da würde ich aber stark empfehlen vorher die Netzplanung gut zu machen, dann muss man da ggf. nur ein größeres Netz routen (bspw. 172.16.x.y -> /16 routen für alle VPN Ziele). Man muss bei der Hex-Schreibweise dann aufpassen, dass man bei der Kompaktschreibweise wirklich nur die notwendigen Bits schreibt, sonst wird das GW falsch ausgelesen :) Cheers \jens

@viragomann said in Firtz.box -> DNS kann ich aufgelöst werden: Du hast vollkommen Recht, allerdings solltest du diese Info an AVM richten. Die werden das hier nicht lesen. Ist schon passiert. BTW: Die ICANN warnte u.a. genau vor solchen Dingen bereits seit 2013 als man über gTLDs nachgedacht hatte. 2014-5 gab es dann diverse Scans nach bekannten TLDs, die einfach genutzt wurden ohne dass sie legitime TLDs waren. Dazu zählten dann auch .home oder .box und Co. Daher kamen die gTLDs und dann bestimmte Namen auf eine Sperrliste, die für 2-3 Jahre geblockt wurden um solche Probleme wie beschrieben zu vermeiden bzw. dem Hersteller Änderung zu ermöglichen. https://www.icann.org/resources/pages/name-collision-2013-12-06-en https://www.icann.org/en/system/files/files/name-collision-mitigation-final-28oct15-en.pdf Dem TO hilft es nicht wirklich. Er sollte nur mitnehmen, dass er seine FB nennen kann, wie er möchte. Wenn er allerdings eine public Domain verwendet, muss er sich dessen Konsequenz bewusst sein. Für mich wäre die zu verschmerzen. Und genau das hab ich geschrieben: Man kann es machen (und sich der Risiken bewusst machen, die die meisten eben nicht wissen, daher ist es IMHO sinnvoll aufzuklären!) indem man ein DNS Host Override anlegt. Man sollte es aus angegebenen Gründen eher nicht tun und vermeiden, sondern eine interne Domain (wie .home.arpa statt .box) nutzen oder eine eigene wenn vorhanden. Die Fritz unterstützt auch andere Namen in ihrer Oberfläche. Genau das war meine Aussage und Intention. Das "hilft nicht" halte ich an der Stelle allerdings für falsch, denn da es von AVM so gepusht wird und man nirgends über Probleme/Gefahren aufgeklärt wird, kann man es auch nicht besser machen. Genau daher habe ich das so ausführlich beschrieben, dass und warum es problematisch ist und man es lassen sollte. Dann kann jeder für sich eine informierte Entscheidung treffen, ob er sich so einen Hostname basteln möchte, lieber einen anderen Namen nimmt oder es ganz sein lässt. Aber wenn man nichts davon weiß, kann man diese Entscheidung sinnvoll eben nicht treffen. :) Cheers

Schaue lieber noch mal in einem Netzrechner vorbei und schaue was du mit der Subnetmask beinflussen kannst. So ist ein /21 dann ein Supernetz und besteht aus 8 einzelnen /24er Netzen. Netzrechner

@jegr ich bin heute leider nicht dabei... Hoffe im Oktober wieder...

@nonick said in ACME Lets Encrypt CN=R3, Gültig bis: Wed, 29 Sep 2021: Der Beitrag von Jim Pingle kam für mich etwas zu spät, oder ich war wieder mal zu schnell. Kein Ding, der kam jetzt wahrscheinlich wegen mehreren Reports :) Wenn ich nur das alte R3 gelöscht und ein Zertifikat erneuert habe (der HAProxy wurde auch neu gestartet), dann sah das in der Sense zwar alles gut aus, aber bei einem Test auf SSL Labs wurde weiterhin noch der alte Trusted Certificate Path angezeigt. Also in meinem Test lief es problemlos. Aber klar, notfalls kann man alle CAs von LE weghauen, die kommen dann automatisch wieder. :)

@interessierter Was ist denn die Gegenseite? Die Ubiquiti Schüssel sieht den Port flippen oder wer genau? Ansonsten würde ich Kabel oder Injektor auf Funktion testen, no carrier ist eigentlich recht eindeutig dass die Sense da nichts an Signal bekommt. Vielleicht der Injektor dazwischen der Probleme macht oder eben die Verkabelung. Hatte da auch mal ein Kabel, das mit Injektor Probleme hatte. Cheers

@jegr Ja, das stimmt, die erste Korrektur brachte bereits eine deutliche Verbesserung der Ladezeiten, so dass aus meinen 20+ Sekunden schon mal 6...7 Sekunden wurden. Die zweite Anpassung in guiconfig.inc, brachte dann den "Durchbruch". Die Ladezeiten sind wieder bei +-1 Sekunde in Summe. Also wieder optimal. Um es genau zu benennen, ich habe aus dem git die beiden Dateien ../usr/local/www/guiconfig.inc und ../usr/local/www/firewall_rules.php genommen und in meine 2.5.2 einfach nur rein kopiert, dann noch kurz die Attriburte geprüft und getestet. - Einandfrei... Grüße

Wäre es nicht deutlich schlauer, einfach ein zweites WLAN aufzuspannen? Die Unify APs sind doch eigentlich alle Multi-SSID und VLAN fähig oder nicht? Der Switch sollte dabei auch kein Hindernis darstellen. / VLAN 20 \ / SSID 1 (VLAN 20) Router Switch - AP \ VLAN 40 / \ SSID 2 (VLAN 40)

Also so: [image: 1629635101227-7b94aea2-e221-451f-bc11-9dc064de88d7-image.png]

@tanjix Mahlzeit, ich versuche mich ja bei einem Tunnel als Man in the Middle um CG-Nat zu umgehen. eine zweite pfSense ist auf einem VPS, die soll die entsprechenden Anfragen entgegen nehmen und diese über den Tunnel zu mir leiten. So die Theorie. Bei mir geht auch pingen in alle Richtungen, aber kein Portforward. Darf ich mich hier mit meinen Screenshots anhängen um eventuell mit Eurer Hilfe zur Lösung zu kommen??

@p54 said in [solved] Windows Domain PFSense LAN-rules werden nicht angewendet: Naja, dann muss ich mein VLAN für die Clients zum Abschluss bringen Ein kluger Schritt, einen entsprechenden Switch vorausgesetzt. :-)

@nocling said in Provider/ Anschlusswechsel - etwas ändern?: Ich denke nicht das hier IPv4 und IPv6 einen Unterschied machen was die States der Firewall angeht. Das hängt davon ab, welche Funktion die Fritze wirklich macht. Ist sie die Komponente die die Verbindung aufbaut, so wird die FW der Fritze aktiv und dann kommt die von Dir genannte Einschränkung zum Tragen (war mir nicht so klar, da ich nicht auf die Idee kam, dass es in dieser Hinsicht so schnell als Bremse agieren kann). Ist die nicht die Komponenten die die Verbindung aufbaut - s.g IP Klient (ist wohl auch der Modus was Du favorisierst) wird die FW deaktiviert, weil nichts zu tun. Gut das ich gefragt habe.

@noplan said in Open VPN Verbindungen pro User limitieren: funktioniert alles nicht wenn du mittels cso dem user eine definierte IP mitgibst so wie bei uns hier Die IP im CSO weglassen?? Diesen Gedanken hatte ich noch gar nicht gesponnen.

Der muss extra aktiviert werden, ist halt der neue und viel effektivere Modus. Aber da Dev und neu schaltet den wohl nicht jeder ein. Läuft aber wirklich gut und viel effektiver als der normale Mode vom Unbound.

@noplan Moin :) also die Firewall läufz, hab alles nochmal neu installiert. ping geht auch zu google. Internet ist da. Erstmal nur ein Wan Lan geht auch. Was ich nicht hin bekomm ist das Routing. Hast du einen tipp für mich? Ich hab keine Idee wie ichs mach. Unifi controller hat die 192.168.0.1 PFsense 192.168.0.160 Rechner hat 192.168.2.38 wenn ich am rechner das gateway auf 192.168.0.160 statt 0.1 ändern habe ich kein internet. auf der pfsense habe ich bei lan & Wan Firewall rules erstmal allow any eingestellt

Ja wir haben das im talk in der user group durchgeplaudert... (also vorteile u handling, u wie man's angehen könnte.. Also @JeGr hat mal den Abriss gemacht... Ich finds geil) Ich glaub wir sollten netgate eine crowdfunding Für das Portal vorschlagen... PfS braucht sowas