Messages

Habe ich entsprechend geändert, die anderen Ports sind deaktiviert.

Hat auf anhieb funktioniert, habs anscheinend doch verstanden :)

Na, dann ist ja gut :)

Ich habe noch ein Problem.
Meine Synology NAS mit aktuell 2 Ports.
Port 1: 192.168.1.251
Port 2. 192.138.30.11

Nun hat das NAS eine 10 Gbit\s Karte bekommen und soll aus 2 VLANS erreicht werden.
Mache ist dies unter
Firewall -->NAT --> Port Forwarding
oder
 Firewall --> Rules und in dem entsprechenden VLAN?

Vielen Dank für deine Hilfe!!

Stimmt, sonst würde es ja nicht funktionieren.

Aber was haben die ständigen Versuche dann auf sich?
Die IP gehört zu einem Roboter Staubsauger.

Hallo Patrick,
ja entschuldigung ich meinte natürlich Ping.

ich habe dies jetzt wie im Anhang eingestellt.
Anstatt Floating Regeln habe ich dies unter Restricted net gemacht,wird aber noch geändert der Übersichtlichkeit halber.

Funktioniert!


Sollte den noch der Broadcast 192.168.50.255 erlaubt werden?

Nun können die VLANs die Zeitserver erreichen. Aber wie schaffe ich es das die VLANs ihre eigenen Gateways erreichen können?
Diese veruschen sich unter TCP Port 7 oder icmp zu erreichen.

Sollte die Regel dann wie bei DNS

Source: Restricted net
Destination: This Firewall
Destination Port: 7
Protocol: TCP

sein?


EDIT: Ich habe die Regel so erstellt:

Source: Restricted net
Destination: This Firewall
Destination Port: 7
Protocol: TCP

und

Source: Restricted net
Destination: This Firewall
Destination Port:
Protocol: ICMP
ICMP TYP: Echo request

Geht das so in ordnung?

Hallo Patrick,
vielen Dank für die schnelle Antwort!

Wie sollte diese Regel den aussehen? Damit tu ich mich noch etwas schwer..

Gruß Luca

Hallo, es haben sich mit der Zeit noch ein paar Fragen aufgetan wo ich noch etwas Nachhilfe von euch bräuchte.

Ich habe mehrere VLANs erstellt und mit der Regel


Interface: Restricted
Source: Restricted net
Destination: This Firewall
Protocol: TCP/UDP
Destination port: DNS
Action: allow

Interface: Restricted
Source: Restricted net
Destination: !Restricted net (destination invert)
Protocol: any
Destination port: any
Action: allow

den Verkehr untereinander geblockt.

Nun habe ich im Firewall Log immer wieder gesehen das Anfragen von zum bsp. 192.168.20.10 --> 192.168.20.1 oder/und 192.168.20.255 geblockt werden.
Aber ist für dieses VLAN nicht die 192.168.20.1 das eigene Gateway?


Ich habe ein Screenshot von den Logs gemacht.

Hello, I have the same problem.

Resetting all local conflicts unfortunately doesn't work.


Furthermore, the values are completely incorrect (see attachment).

Hallo viragomann,

die IP Adresse für die Synology ist folgende
192.168.1.251 im LAN
und
192.168.30.11 im VLAN

ich konnte dies erstmal in Adguard lösen (Siehe Foto)
Hier musste ich die 192.168.30.11 wieder entfernen da logischerweise meine VLAN Regeln den Traffic aus 192.168.1.1 zu 192.168.30.1 blocken.

Mein Upstream DNS Server in Adguard ist die 192.168.1.1:5353
Meine Einstellung von Unbound (Siehe Foto)
Aktiv habe ich keine Einstellung geändert, nur die alten port forwarding rules auf das neue Interface angepasst.

Moin,

wie bereits im anderen Thread bereits geschrieben wurde wir gestern an Glasfaser angebunden.
Vorher hatte ich die OPN hinter einem Speedport Smart 4 mit WAN als DHCP.

Ich habe nun wie in der Anleitung beschrieben die Interfaces angelegt und der Anschluss funktioniert auch.

In der Übersicht der Gateway wurde am Anfang der WAN_GW ohne IP angezeigt. Ich musste das WAN mit dem PPoE Interface (Siehe Bild) verknüpfen damit die IP angezeigt wird. Ist dies so richtig?

EDIT: Ich habe das ganze mit dem Gateway rückgängig gemacht und den Eintrag WAN_GW gelöscht nun wird im Dashboard die IGC0 Angezeigt.



Nach der Umstellung funktioniert der zugriff über den Domain Namen meiner Synology nicht mehr, Zugriff über IP aus dem Heimnetz oder aus dem Internet über die Domain ist möglich. Eigentlich habe ich an dieser Einstellung nichts geändert.
Betrieben wird Adguard + Unbound,
EDIT: Ich konnte unter AdGuard --> Filter -->DNS Umschreibung die Domain und die interne IP eingeben, funktioniert nun.

Vielen Dank!

Hallo meyergru,

ich habe die Regel entsprechend geändert und nun funktioniert es.
Dies hatte ich bereits im Post oben editiert.

Hier nochmal die Regeln.
Es Funktioniert nun

[igc0_vlan7_PPoE]

Hier die Outbound Regel



EDIT: Klar die Regeln sind ja auch für das WAN und nicht für die Schnitstelle : igc0_vlan7_PPoE
Habe eine Inbound NAT Regel erstellt mit Port 5060 sowie 7078:7109 und die Telefonie funktioniert.

Moin leute,
wir haben endlich den Glasfaseranschluss freigeschaltet bekommen.
Die OPNsense verbindet sich über PPoE mit der Stadtwerke Münster (1&1 Versatel).
Auf der Fritzbox 7490 (war noch vorhanden genau so wie die alten Telefone mit TAE Stecker) die Fritzbox ist als IP Client im LAN Netz,die Rufnummern sind angemeldet und eine Verbindung wird aufgebaut.
Der Anschluss kann angerufen werden und auch raus telefonieren und ebenfalls sprechen, kann die gegenseite aber nicht hören.
In den Firewall Logs bekomme ich folgendes Ergebnis.
Egal ob eingehend oder ausgehend.

Als Regel habe ich ledeglich die NAT Outbound Regeln festgelegt.
Aber nach meinem Verständnis habe ich doch den geblockten Port 7078 für die Fritzbox geöffnet oder etwa nicht?
 

Hallo Pinockel,

ich habe ein ähnliches vorhaben auch klein angefangen und nun mittlerweile ca. 100 Clients in meinem Omada Setup von TP-Link.
Die Geräte sind meist nur halb so teuer (Die AP auf jeden Fall) und bin damit eigentlich super zufrieden.
Ich haben einen TL-SG3428XMP und 7 verschieden AP´s am laufen mit 7 eigenen SSID´s und eigenen VLANS. Ich erreiche damit eine stabile Abdeckung von ca 35.000 m² (davon aber auch 30.000 m² freie Fläche.)
Funktioniert bin glücklich und fand es fast selbst erklärend :)

PS: Habe dazu das Sicherheitssystem von TP-Link VIGI, läuft super mit Omada zusammen.

Gruß Luca

Hallo,
um das Thema abzuschließen habe ich die Lösungen gefunden.

In Adguard wie im Screenshot zu sehen muss der Puffer auf 0 gesetzt werden, da Unbound die DNS Einträge speichert.

Das Problem mit den DNS Einträgen bei meinem NVR ist auf ein Firmwarebug zuruckzuführen laut Support.