Hallo zusammen

vielen Dank für die Hinweise.
Wie gut sind denn die genannten IPU´s in sachen Qualität und Ausdauer ?

@viragomann Darum meinte ich auch, es könnte das oder die NAT Problematik sein:

There are also known issues with NAT, notably that NAT to the interface address works but 1:1 NAT or NAT to an alternate address does not work.

Da ich nicht weiß/sehen kann, wie @zickzack2021 die sensen auf beiden Seiten konfiguriert hat und was da an NAT, CARP oder sonstwas dran hängt, bin ich da auch im Blindflug, wenngleich ich dir recht gebe, dass sich das im Prinzip schon eher nach asym. Routing anhört. Aber auch da müssen wir ja raten, weil wir nicht wissen, wie Standort A/B ins Internet angebunden sind und ob die Sensen auch das Default GW im Netz sind. :)

Guten Abend zusammen 😊

Bei mir hatte es bisher auch fehlerfrei funktioniert, aber von jetzt auf nachher nicht mehr.
Ich habe jetzt über ne Woche nichts mehr damit gemacht und nun funktioniert wieder alles.

Ich habe aber keine Ahnung wieso🤔

Das Thema kann damit geschlossen werden.

Schönen Abend euch 😊

Resolver läuft?
Regelwerk für das VLAN Int erlaubt Zugriff auf this Firewall mit dem Dienst DNS?

Wenn kein Regel vorhanden ist die das erlaubt, dann greift die implicit deny, die siehst du aber nicht, die ist unsichtbar aber immer auf jedem Interface ganz unten vorhaden.

hi @jegr, ja ich habe dank deiner Info einfach mal die pfB_PRI1_v4 manuell in die Interface Rules mit einem anderen Bezeichner hinterlegt und nun klappts auch wieder. Stört mich auch nicht wenn die autorule von pfBlocker nicht aktiv ist, aber es ist schon seltsam gewesen, weil es eben immer bis Dato funktioniert hatte.

Soll mir auch recht sein wie du schon selbst meintest wenn nicht "auf Gutdünken" irgendwo eine neue Regel anglegt wird durch die Anwendung selbst.

Danke für die Unterstützung!

VG

@mx-hero-0 Da kann ich mich tatsächlich Mic nur anschließen. Du versucht eine Firewall Version zu "analysieren", die Okt. 2017 released wurde und es nicht nur etliche Updates seither gab, sondern auch etliche Sicherheitsfixes und Verbesserungen. 4 Jahre alte Software auf alter Hardware, da ist potentiell ein Broadcast Log noch das Kleinste der Probleme :/

Dringend updaten, vor 4 Jahren bspw. ne APU2 Büchse gekauft (auch wenn ich sie nicht mag), dann hätten sich die ~200€ schon lange rentiert

Cheers

@viragomann said in SMB Freigabe auf VIP NATen?!?:

Die ist einfach im Hostnamen (Computername) zu setzten.

Kannte ich auch noch nicht, jetzt mal eingerichtet, danke.

Du und @JeGr solltet allerdings recht behalten, das Backup funktioniert inzwischen generell nicht mehr. 😠

@benjaminbeckcsl
Ohne Konfiguration ist das echt schwer

man nimmt was man eben an hardware hat 😅

@gabylein said in internes Routing:

Die RFC1918 Regel unterbindet das aber , also kommt kein Connect zustanden.

Welche RFC1918 Regel? Von LAN/internen Netzen aus gibt es default keine.

@gabylein said in internes Routing:

IP aus Netz1 über Gateway 1 mit dann fester IP 1 ->
feste IP 2 Gateway 2 auf die jeweilige intere IP spricht.

Klingt erstmal nicht ideal. Wozu möchte man unnötig den Traffic 2x durch die Firewall ziehen wenn man den Host intern direkt erreichen kann?
Ansonsten: kann man machen, muss nur das Outbound NAT richtig konfigurieren. Wenn der Weg sauber gebaut ist, das Routing und die Interface Configs stimmen, sollte es da auch keine Probleme geben, dass man - so unnötig es ist - einmal mit der Kirche ums Dorf fahren kann ;)

Wie und wo schaltet ich das interene Routing aus ?

Routing schaltet man nie aus, das ist Quark. Ohne Routing läuft gar nichts. Der Weg ist wahrscheinlich nicht korrekt konfiguriert. Es ist recht egal, wenn man über irgendeinen Client in LAN1 -> WAN 1 -> WAN 2 IP -> wieder rein -> LAN 2 -> irgendein Host aufrufen will. Das geht. Aber die Kette muss saubere Outbound NAT auf WAN1 nutzen (damit die interne IP maskiert wird mit WAN1 IP) und dann kann die auch via WAN2 wieder rein in LAN2 rutschen ohne Problem weil der Client dann denkt, die Anfrage kommt von draußen.

Wie aber oben gesagt: aus Routing Sicht macht das keinen Sinn und sowas würde man versuchen zu vermeiden um direkt zu routen um sich die ganzen Lags und Latenzen und Bandbreitenprobleme der WANs/routing loops zu sparen.

Cheers

@bob-dig @NOCling war es unklar bzw. er meinte es andersrum, aber PF arbeitet in seinem File entsprechend top-down:

Aliase Tabellen NAT (Forwards); BiNAT, Outbound Rules Floating Gruppen Interfaces

der Reihe nach ab. Und ja auch Aliase und Tabellen sind Entities, die im Regelwerk ne Rolle spielen. Wären die nicht zuerst eingelesen, könntet ihr sie nicht in NAT oder Regeln verwenden, daher sind sie mit aufgelistet. Und für die generelle Info ist die Party nie vorbei :P

@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:
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. :)