[Sammelthread] MikroTik Geräte

Wie gesagt, nicht optimal..vor allem, wenn man mehrere Quicksets nacheinander ausprobiert.
Hier gibt es alles zum "durchforsten": https://help.mikrotik.com/docs/display/ROS/RouterOS
Step 1: https://help.mikrotik.com/docs/display/ROS/First+Time+Configuration
Step 2: https://help.mikrotik.com/docs/display/ROS/Securing+your+router

Habs umgesetzt und auch gleich die Firewall wie hier konfiguriert:


Wie gewöhnlich sind denn Logmeldungen der Regeln "Drop tries to reach not public addresses from LAN" und "Drop invalid"? V.a. mein Unraid-Server wird hier regelmäßig "abgefangen".

Freund, der Sinn dieses Port-Forwardings, wie schon bei Deiner Fritz und nun beim MT, ist doch den Zugriff von aussen zu ermöglichen.
Die Regel anzuwenden / zu installieren und dann nicht auszuprobieren ist wie kochen und ohne abschmecken zu servieren, findest Du nicht ;-)


-> https://help.mikrotik.com/docs/display/ROS/NAT#NAT-HairpinNAT

Mittlerweile funktioniert es Dank dieses Hinweises:



...ja, aber es ist vor allem auch dazu da, dass Du Dich nicht mit einer sinnlosen Firewall-Regel aussperrst ;-)
Am besten einfach einen Port des RB5009 dafür reservieren (mit PVID = <Deine-VLAN-ID)...dann kannst Du immer noch mit einem Laptop und nem Patchkabel in den Keller gehen...
Wenn Du Winbox nutzt, probiere/benutze auch den Safe-Mode, wenn Du was ausprobieren willst: https://help.mikrotik.com/docs/display/ROS/Configuration+Management#ConfigurationManagement-SafeMode

Das muss ich mir noch in Ruhe anschauen, bin hierzu noch nicht gekommen. Kann man denn so ein "Management VLAN" auch aufbauen, ohne zwangsläufig für die anderen Netzwerkgeräte auch VLANs einzurichten?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
OK, Du hast die einfache Version der Firewall gewählt. Ich denke, die nutzt kaum Jemand ;-)
Aber erstmal OK...Drops sollte es eigentlich keine oder nur selten geben, für Traffik der von Innen kommt(im LAN passiert.
Wie gewöhnlich sind denn Logmeldungen der Regeln "Drop tries to reach not public addresses from LAN"
...das kommt daher:
Code:
add action=drop chain=forward comment="Drop tries to reach not public addresses from LAN" dst-address-list=not_in_internet in-interface=bridge log=yes log-prefix=!public_from_LAN out-interface=!bridge

...bedeutet, das Verbindungen mit Ziel interner IPs nicht im LAN bleiben, sondern eben ins WAN gehen, wo sie nix zu suchen haben.
Bedenke, dass diese Mini-Firewall davon ausgeht, dass alle Ports, ausser eth1 - welcher WAN ist - an der Bridge hängen....evtl. hast Du eben nicht alle Ports ausser WAN an der Bridge?

und "Drop invalid"? V.a. mein Unraid-Server wird hier regelmäßig "abgefangen".
siehe oben...da kommen Pakete für IP-Verbindungen bei der Regel an, die eigentlich nicht funktionieren können (invalid sind).
Evtl. eine Wechselwirkung Deiner "Verdrahtung", ungültigen Adressen - dieses Setup geht vom IP-Segment 192.168.88.0/24 aus und evtl. nutzt Du ein Andeers und hast etwas vergessen umzustellen - oder auch mit dem Hairpin-NAT.

Kann man denn so ein "Management VLAN" auch aufbauen, ohne zwangsläufig für die anderen Netzwerkgeräte auch VLANs einzurichten?
Ja, natürlich....die default VLAN-ID ist "1"..und genau diese ID sollte man für das Management VLAN eben nicht verwenden.
Damit braucht man eben nur eine andere ID einrichten und für alles Andere den Standard auf ID=1 lassen....dann sind alle im gleichen VLAN, ausser der Management-Port
Aber der SAFE-Mode funzt gut...muss man nur dran denken.
 
OK, Du hast die einfache Version der Firewall gewählt. Ich denke, die nutzt kaum Jemand ;-)
Aber erstmal OK...Drops sollte es eigentlich keine oder nur selten geben, für Traffik der von Innen kommt(im LAN passiert.

Als ersten Schritt zur Absicherung sind die dort vorgeschlagenen Regeln aber zu gebrauchen, oder?

...das kommt daher:
Code:
add action=drop chain=forward comment="Drop tries to reach not public addresses from LAN" dst-address-list=not_in_internet in-interface=bridge log=yes log-prefix=!public_from_LAN out-interface=!bridge

...bedeutet, das Verbindungen mit Ziel interner IPs nicht im LAN bleiben, sondern eben ins WAN gehen, wo sie nix zu suchen haben.

Ich hab jetzt leider keine aktuelle Meldung im Log, da die 1000 Einträge seit gut 13 Uhr schon wieder voll sind, aber fast ausschließlich die invalid-forward-Regel betreffen...

Bedenke, dass diese Mini-Firewall davon ausgeht, dass alle Ports, ausser eth1 - welcher WAN ist - an der Bridge hängen....evtl. hast Du eben nicht alle Ports ausser WAN an der Bridge?

Ich habe grundsätzlich alle genutzten Ethernetports (bis auf eth1, welcher für die PPPOE-Verbindung benutzt wird) der Bridge hinzugefügt.


Code:
/interface bridge
add name=bridge port-cost-mode=short
add name=containers port-cost-mode=short
/interface bridge port
add bridge=bridge interface="ether2 - Unraid-Server" internal-path-cost=10 path-cost=10
add bridge=bridge interface="ether3 - EAP650 EG" internal-path-cost=10 path-cost=10
add bridge=bridge interface="ether4 - EAP650 1. OG" internal-path-cost=10 path-cost=10
add bridge=containers interface=veth1 internal-path-cost=10 path-cost=10
add bridge=containers interface=veth2
/interface bridge settings
set use-ip-firewall=yes

siehe oben...da kommen Pakete für IP-Verbindungen bei der Regel an, die eigentlich nicht funktionieren können (invalid sind).

Code:
invalid forward: in:bridge(ether3 - EAP650 EG) out:pppoe-out1, connection-state:invalid src-mac **:**:**:**:**:**, proto TCP (ACK,FIN), 192.168.188.22:12578->23.88.74.254:80, len 40

Hier als Beispiel. Die Anfrage kommt von meinem Laptop, keine Ahnnung wieso das ganze hier verworfen wird. Laut tracert landet man bei der angesteuerten IP-Adresse bei irgendwelchen Hetzner-Servern,; dort habe ich zwar eine Storagebox, jedoch besteht keinerlei Verbindung zu dieser von meinem Laptop aus.

Evtl. eine Wechselwirkung Deiner "Verdrahtung", ungültigen Adressen - dieses Setup geht vom IP-Segment 192.168.88.0/24 aus und evtl. nutzt Du ein Andeers und hast etwas vergessen umzustellen - oder auch mit dem Hairpin-NAT.

Darauf habe ich schon geachtet, denn mein internes Netz läuft auf 192.168.188.0/24 (bzw. DHCP von 192.168.188.20-254)

So sehen die Firewallfilterregelungen derzeit aus:

Code:
/ip firewall filter
add action=accept chain=input comment="default configuration" connection-state=established,related
add action=accept chain=input src-address-list=allowed_to_router
add action=accept chain=input protocol=icmp
add action=drop chain=input
add action=fasttrack-connection chain=forward comment=FastTrack connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="Established, Related" connection-state=established,related
add action=drop chain=forward comment="Drop invalid" connection-state=invalid log=yes log-prefix=invalid
add action=drop chain=forward comment="Drop tries to reach not public addresses from LAN" dst-address-list=not_in_internet in-interface=bridge log=yes log-prefix=!public_from_LAN out-bridge-port=!veth1 out-interface=\
    !bridge
add action=drop chain=forward comment="Drop incoming packets that are not NAT`ted" connection-nat-state=!dstnat connection-state=new in-interface=ether1 log=yes log-prefix=!NAT
add action=jump chain=forward comment="jump to ICMP filters" jump-target=icmp protocol=icmp
add action=drop chain=forward comment="Drop incoming from internet which is not public IP" in-interface=ether1 log=yes log-prefix=!public src-address-list=not_in_internet
add action=drop chain=forward comment="Drop packets from LAN that do not have LAN IP" in-interface=bridge log=yes log-prefix=LAN_!LAN src-address=!192.168.188.0/24
add action=accept chain=icmp comment="echo reply" icmp-options=0:0 protocol=icmp
add action=accept chain=icmp comment="net unreachable" icmp-options=3:0 protocol=icmp
add action=accept chain=icmp comment="host unreachable" icmp-options=3:1 protocol=icmp
add action=accept chain=icmp comment="host unreachable fragmentation required" icmp-options=3:4 protocol=icmp
add action=accept chain=icmp comment="allow echo request" icmp-options=8:0 protocol=icmp
add action=accept chain=icmp comment="allow time exceed" icmp-options=11:0 protocol=icmp
add action=accept chain=icmp comment="allow parameter bad" icmp-options=12:0 protocol=icmp
add action=drop chain=icmp comment="deny all other types"

Und so die Adresslisten:

Code:
/ip firewall address-list
add address=192.168.188.20-192.168.188.254 list=allowed_to_router
add address=0.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=172.16.0.0/12 comment=RFC6890 list=not_in_internet
add address=192.168.0.0/16 comment=RFC6890 list=not_in_internet
add address=10.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=169.254.0.0/16 comment=RFC6890 list=not_in_internet
add address=127.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=224.0.0.0/4 comment=Multicast list=not_in_internet
add address=198.18.0.0/15 comment=RFC6890 list=not_in_internet
add address=192.0.0.0/24 comment=RFC6890 list=not_in_internet
add address=192.0.2.0/24 comment=RFC6890 list=not_in_internet
add address=198.51.100.0/24 comment=RFC6890 list=not_in_internet
add address=203.0.113.0/24 comment=RFC6890 list=not_in_internet
add address=100.64.0.0/10 comment=RFC6890 list=not_in_internet
add address=240.0.0.0/4 comment=RFC6890 list=not_in_internet
add address=192.88.99.0/24 comment="6to4 relay Anycast [RFC 3068]" list=not_in_internet

Und so die NAT-Regeln:

Code:
/ip firewall nat
add action=masquerade chain=srcnat comment="Masquerade PPPOE" out-interface=pppoe-out1
add action=dst-nat chain=dstnat comment="Wireguard Tower" dst-port=51820 in-interface-list=all protocol=udp to-addresses=192.168.188.24 to-ports=51820
add action=masquerade chain=srcnat comment="Masquerade Container" src-address=172.17.0.0/24
add action=dst-nat chain=dstnat comment="Weiterleitung AdGuardHome" dst-address=192.168.188.1 dst-port=3000 log=yes protocol=tcp to-addresses=172.17.0.2 to-ports=3000
add action=dst-nat chain=dstnat comment="Nginx HTTP" disabled=yes dst-address-type=local dst-port=80 log=yes log-prefix="nginx http" protocol=tcp to-addresses=192.168.188.24 to-ports=1880
add action=dst-nat chain=dstnat comment="Nginx HTTPS" dst-address-type=local dst-port=443 log=yes log-prefix="nginx https" protocol=tcp to-addresses=192.168.188.24 to-ports=18443
add action=masquerade chain=srcnat comment="Hairpin NAT Nginx" dst-address=192.168.188.24 dst-port=18443 log=yes log-prefix=hairpin out-interface=bridge protocol=tcp src-address=192.168.188.0/24

Soweit ich das jetzt beurteilen kann, steht dort kein kompletter Blödsinn drinnen (zumindest habe ich mich nahezu ausschließlich an die Hilfeseiten von Mikrotik gehalten).

Ja, natürlich....die default VLAN-ID ist "1"..und genau diese ID sollte man für das Management VLAN eben nicht verwenden.
Damit braucht man eben nur eine andere ID einrichten und für alles Andere den Standard auf ID=1 lassen....dann sind alle im gleichen VLAN, ausser der Management-Port
Aber der SAFE-Mode funzt gut...muss man nur dran denken.

OK. Da muss ich mich jetzt mal einlesen.
 
Als ersten Schritt zur Absicherung sind die dort vorgeschlagenen Regeln aber zu gebrauchen, oder?
Ja, natürlich.
Die "advanced" Version ist flexibler, weil sie mit Interface-Listen arbeitet und man einfach dann eine Regel für "LAN" oder "WAN" nehmen kann, falls eben mehrere Interfaces betroffen sind.
Ausserdem ist die quasi Standard und wird halt auch bei Beispielen aus dem I-net zu finden sein....das macht es komplexer, wenn man davon mal was nachbauen will.

Ich habe grundsätzlich alle genutzten Ethernetports (bis auf eth1, welcher für die PPPOE-Verbindung benutzt wird) der Bridge hinzugefügt.
OK, gut...aber Du hast ne 2te Bridge für Deine Container auf dem RB5009 gebaut, die eben nicht "bridge" heisst...was für Container laufen da...Adguard? Evtl. kommt es daher?
Hat die Bridge "containers" auch ne eigene IP aus dem Segment 172.17.0.0/24 .... braucht man das srcnat dafür überhaupt - sorry, nutze keine Container, mein RB4011 ist dafür zu klein und auf meinen AC3 war das nie stabil...hatt aber eben keine 2te Bridge und scrnat Regel für Adguard Container...ist aber schon was her.

Soweit ich das jetzt beurteilen kann, steht dort kein kompletter Blödsinn drinnen (zumindest habe ich mich nahezu ausschließlich an die Hilfeseiten von Mikrotik gehalten).
Ja, das sieht soweit nicht falsch aus.
BTW: das Wireguard auf dem unraid könntest Du auf den RB5009 verlegen, der kann ja WG nativ und hat auch Bumms....eine Portweiterleitung weniger ;-)

Code:
invalid forward: in:bridge(ether3 - EAP650 EG) out:pppoe-out1, connection-state:invalid src-mac **:**:**:**:**:**, proto TCP (ACK,FIN), 192.168.188.22:12578->23.88.74.254:80, len 40
Hier als Beispiel. Die Anfrage kommt von meinem Laptop, keine Ahnnung wieso das ganze hier verworfen wird. Laut tracert landet man bei der angesteuerten IP-Adresse bei irgendwelchen Hetzner-Servern,; dort habe ich zwar eine Storagebox, jedoch besteht keinerlei Verbindung zu dieser von meinem Laptop aus.
Tja, hmmm... TCP(ACK/FIN) bedeutet was? :unsure: Das da ne Verbindung bestand und der Laptop sie schliessen will?
Findest Du was zu den IPs im IP contrack (Firewall - Connections)?

Ich hab jetzt leider keine aktuelle Meldung im Log, da die 1000 Einträge seit gut 13 Uhr schon wieder voll sind, aber fast ausschließlich die invalid-forward-Regel betreffen...
Tja, also ich bin von hier aus auch überfragt...wenn es die Container nicht sind, erst recht :rolleyes2:
 
Fluppt prima.
VLANs unter Interfaces/VLAN erstellen.
Feste IPs unter IP/Address vergeben, in der Bridge und den Ports L3HW aktivieren (war bei mir default an).
Traffic geht direkt von der VM über die Switches zum Desktop.

ich bin leider noch nicht dazu gekommen es umzusetzen!

Hast Du auf den Clients noch Routen mit den IP Adressen des Mikrotiks angelegt?

@Weltherrscher könntest Du noch kurz sagen, wie Du das Offloading eingerichtet hast? Mittels Routen auf den Clients?
 
Hat einer hier praktisch einen Glasfaser-Anschluss der Deutschen Glasfaser eingerichetet? Kennt jemand gute Links zum Start dazu?

Vielen Dank.
 
Ja, ist nichts besonderes dran. IPv4 und IPv6 jeweils per DHCP ziehen, VLAN erledigt dein ONT.
 
Für das CGNAT müssen dann die Tabellen eingepflegt werden? Leider ist die IP-Adresse bei mir eine andere, fängt aber auch mit 100 an.
 
Was für Tabellen? Das CGNAT findet ja nicht bei dir statt, sondern bei der DG.
 
@Weltherrscher könntest Du noch kurz sagen, wie Du das Offloading eingerichtet hast? Mittels Routen auf den Clients?
Hi sorry für die späte Rückmeldung:
Nö, hab auf den Clients keine Routen eingestellt.
Es reicht scheinbar, dass die VLANs ne IP haben.
Zum Thema MAC-Adressen:
1705306699559.png

Leider alle drei dieselbe MAC (die von der Bridge).
MACVLAN schaue ich mir mal an, wenn ich wieder Zeit habe...

//Edith:
Zumindest sehe ich bei Transfers innerhalb desselben VLANs (Desktop hat ne IP im VLAN 30 und NAS auch) jetzt keinen Traffic mehr auf dem Interface zur Firewall.
Also ist INDIREKT auf den Clients ne Route in das entsprechende VLAN vorhanden (eben über das VLAN-Interface).
 
Zumindest sehe ich bei Transfers innerhalb desselben VLANs (Desktop hat ne IP im VLAN 30 und NAS auch) jetzt keinen Traffic mehr auf dem Interface zur Firewall.
...auch bei Inter-VLAN Traffic, zB zwischen 30 und 50, sollte nur kurz was in der Firewall "aufblitzen", bis die Verbindung ausgehandelt ist.

Also ist INDIREKT auf den Clients ne Route in das entsprechende VLAN vorhanden (eben über das VLAN-Interface).
für Den Fall, selbe VID und gleiches Netz, wird ja gar kein Routing (L3) genutzt, sondern ARP (L2).

Leider alle drei dieselbe MAC (die von der Bridge).
MACVLAN schaue ich mir mal an, wenn ich wieder Zeit habe...
Ich glaube MACVLAN wird nicht gehen, auf einem Bridge-Interface, wenn ich die Help-Seite richtig interprtiere.
Wenn der DHCP-Server auf der Sense liegt, würde ich den Link zur Sense im CRS als Trunk-Port definieren....alle VLAN-IDs da rein...eine separate ID für WAN.
Dann in der Sense DHCP-SRV auf den VLANs aktivieren: https://homenetworkguy.com/how-to/configure-dhcp-vlans-opnsense/ ...dann sollte die Bridge, trotz gleicher MAC jeweils eine IP aus dem VLAN beziehen können.
 
Ja, natürlich.
Die "advanced" Version ist flexibler, weil sie mit Interface-Listen arbeitet und man einfach dann eine Regel für "LAN" oder "WAN" nehmen kann, falls eben mehrere Interfaces betroffen sind.
Ausserdem ist die quasi Standard und wird halt auch bei Beispielen aus dem I-net zu finden sein....das macht es komplexer, wenn man davon mal was nachbauen will.

Ich hab mir jetzt mal diese "Anleitung" hier zumütegeführt:


Das scheint mir ganz ordentlich zu sein :)

OK, gut...aber Du hast ne 2te Bridge für Deine Container auf dem RB5009 gebaut, die eben nicht "bridge" heisst...was für Container laufen da...Adguard? Evtl. kommt es daher?
Hat die Bridge "containers" auch ne eigene IP aus dem Segment 172.17.0.0/24 .... braucht man das srcnat dafür überhaupt - sorry, nutze keine Container, mein RB4011 ist dafür zu klein und auf meinen AC3 war das nie stabil...hatt aber eben keine 2te Bridge und scrnat Regel für Adguard Container...ist aber schon was her.

Ja, die zweite "Bridge" ist für die Docker Container. Diese haben auch ihren eigenen Adressraum.

Die srcnat-Regel wird von Mikrotik selber erwähnt:



Ja, das sieht soweit nicht falsch aus.
BTW: das Wireguard auf dem unraid könntest Du auf den RB5009 verlegen, der kann ja WG nativ und hat auch Bumms....eine Portweiterleitung weniger ;-)

Hab ich mittlerweile Dank der Hinweise hier endlich hinbekommen:

 
---snip---
Ich glaube MACVLAN wird nicht gehen, auf einem Bridge-Interface, wenn ich die Help-Seite richtig interprtiere.
Wenn der DHCP-Server auf der Sense liegt, würde ich den Link zur Sense im CRS als Trunk-Port definieren....alle VLAN-IDs da rein...eine separate ID für WAN.
Dann in der Sense DHCP-SRV auf den VLANs aktivieren: https://homenetworkguy.com/how-to/configure-dhcp-vlans-opnsense/ ...dann sollte die Bridge, trotz gleicher MAC jeweils eine IP aus dem VLAN beziehen können.
In den CRSn läuft der DHCP-Client ja auf den extra VLANs (Interface/VLAN), die haben halt dieselbe MAC wie die Bridge, an der sie hängen.
Der Uplink-Port zur opnSense ist bereits ein Trunk (alle VLANs gehen tagged durch).
Die VLANs ziehen einfach keine IP, sie stehen die ganze zeit auf "searching..."...
 
Tja, dann bin ich überfragt...ich vermute aber eben da eher die Sense als Ursache...die ist ja DHCP-SRV...lauscht sie denn da selektiv auf den VLANs?
 
Was für Tabellen? Das CGNAT findet ja nicht bei dir statt, sondern bei der DG.
Das ist mir schon klar, dass das die DG macht. Hier ist es aufgeführt:


Also du meinst man müsse beim RB5009 nur das IPv4 und IPv6 einrichten? Dann läuft die Kiste eigentlich schon? Leider kenne ich meine Zugangsdaten gar nicht. Muss ich da was bei der DG in Erfahrung bringen?

Wie würde das beim RB5009 mit einem DECT-Telefon laufen? Würde so etwas gehen oder nicht?
 
Ich bin grade tatsächlich am überlegen, den HexLite der hier rumliegt als Hauptrouter einzurichten. Im Moment läuft ne OPNsense auf Proxmox, aber ganz glücklich bin ich damit leider nicht. Gerade wenn die DSL-Verbindung mal weg fällt bekommt das Ding es nicht hin, die PPPoE Verbindung wieder auzubauen. Das einzige was dann zuverlässig hilft, ist ein Neustart der sense. Und naja, wenn Proxmox aus geht gar nix mehr :fresse:

Bekomm ich mit dem Hex Lite meine Wünsche soweit umgesetzt?

- Wireguard Server
- DNS Filter am liebsten auf der Kiste, AdGuard oder PiHole, sonst kein DNS wenn der Proxmox aus ist
- DynDNS würd ich dann mal das Script von @toscdesign drauf werfen, macht im Moment n Container
- DSL sind nur 100/50, sollte afaik nicht wirklich Rechenleistung brauchen
 
Ja das geht

DNS Filter am liebsten auf der Kiste, AdGuard oder PiHole, sonst kein DNS wenn der Proxmox aus ist
Nein das geht nicht, da es eine MIPS CPU ist.
Da musst du dann auf Proxmox oder einen Raspberry Pi ausweichen

DynDNS würd ich dann mal das Script von @toscdesign drauf werfen, macht im Moment n Container
Das läuft super stabil, habe es jetzt schon 6Monate im Einsatz und mich Null drum kümmern müssen.

DSL sind nur 100/50, sollte afaik nicht wirklich Rechenleistung brauchen
Das schafft der locker. Nur bei einem Gigabit Anschluss wird's von der Rechenleistung her knapp
 
Nein das geht nicht, da es eine MIPS CPU ist.
Da musst du dann auf Proxmox oder einen Raspberry Pi ausweichen
Meh, das schon wieder kacke. Gibts da die Möglichkeit das ich das in der Config so hinbiege, dass er Primär dann nen externen nimmt und nur wenn der nicht geht selber was macht? Als Backup ist das ja ok, aber im Standardbetrieb hätte ich schon gern den ganzen Traffic dann anders laufend
 
Meh, das schon wieder kacke. Gibts da die Möglichkeit das ich das in der Config so hinbiege, dass er Primär dann nen externen nimmt und nur wenn der nicht geht selber was macht? Als Backup ist das ja ok, aber im Standardbetrieb hätte ich schon gern den ganzen Traffic dann anders laufend

Also ich hab den DHCP-Server so konfiguriert:

1706976079622.png


Als ich vor ein paar Wochen aus Versehen mit Firewall-Regeln den Adguardhome-Container sozusagen kaltgestellt hatte, gingen auch weiterhin DNS-Anfragen durch (deswegen hatte ich das Ganze erst nach ein paar Tagen bemerkt). sodass ich davon ausgehe, dass der Router selber als Ersatz genommen wurde und somit der zweite Eintrag gegriffen hat.
 
Über DHCP will ich das eigentlich vermeiden, da kann ja dann auch das Client Verhalten unterschiedlich sein, wie der die zugeteilten Server verwendet. Wär mir lieber wenn die Anfragen grundsätzlich beim MT landen und der dann weitermacht
 
Du kannst es theoretisch auch direkt unter IP => DNS eintragen:

1706992622252.png
 
So ich hab den Bums gestern Abend einfach mal umgesteckt, nachdem ich die Tage die Config soweit vorbereitet hab. Bin grad eigentlich sehr positiv angetan, hab dem MT ne andere IP gegeben als der Sense. War zum einen für die Config sehr hilfreich damit der im LAN hängt ohne die Clients zu beeinflussen und für die Kisten wo der Kram fest in der Config steht (VMs etc) hab ich jetzt einfach die alte IP der Sense als zweite auf dem LAN Interface eingetragen und jetzt laufen die Anfragen auch wieder.

Bzgl. DNS hab ich grade n Script im Mikrotik Forum gefunden, das klingt nach genau dem was ich gern hätte.

Code:
:local currentDNS [/ip dns get server]
:local piholeDNS "192.168.0.10"
:local backupDNS "1.1.1.2,1.0.0.2"
:local testDomain "www.google.com"

:if ($currentDNS = $piholeDNS) do={
    :do {
        :resolve $testDomain server=$piholeDNS
    } on-error={
        /ip dns set servers=$backupDNS
    }
} else={
    :do {
        :resolve $testDomain server=$piholeDNS
        /ip dns set servers=$piholeDNS
    } on-error={}
}

So wie die Config aktuell läuft hab ich zwar Internet, aber im PiHole taucht als Client nur der MT auf. Taugt mir so nicht wirklich, werd das jetzt dann doch auf PiHole via DHCP umbauen und DNS Anfragen nach extern von anderen Clients einfach am MT abweisen. Hab hier zwar kaum noch Google Geräte, aber die gehen ja hardcoded erstmal auf Google DNS.

Code:
[admin@MikroTik] > ip/dns/print 
                      servers: 192.168.9.3,9.9.9.9
              dynamic-servers: 217.237.148.102,217.237.151.115
 
Ich würd das PiHole Thema grad nochmal gern pushen :d An sich läuft das seit der Umstellung echt gut, aber die PiHole Statistiken nerven mich trotzdem etwas. Mit der *sense war das kein Thema, aber irgendwas macht der MT hier anders. Zum einen tauchen 99% der Requests mit dem MT als Client auf, außer die, die ich manuell vergeben hab (siehe bei der .9.20) da ist zwar der Hostname auch Mist, aber das ist ja wieder n PiHole Thema.

Bekomm ich das im MT noch entsprechend angeapasst, das die Client Request da entsprechend auftauchen? Alternativ war jetzt schon der Gedanke das ich die PiHole IP doch per DHCP verteile und den MT dann als Fallback eintrage. Der geht dann eh auch wieder auf das PiHole bzw. mit dem Script nach extern wenn das PiHole grad nicht läuft. Was aber wiederrum den Nachteil hätte, das ich meine statischen DNS Einträge die zum Ngingx gehen sollen, auch im PiHole pflegen muss.

1707648058468.png
]]
 
Heya, wir haben hier seit einiger Zeit endlich von LTE auf 5G gewechselt. Der Mast ist Sichtlinie so 30m entfernt, das gibt einen wunderbaren Empfang. Ich nutze derzeit einen MikroTik wAP R ac als Backup-Leitung und würde den gerne durch etwas 5G fähiges ersetzen - muss nicht unbedingt MikroTik sein, wäre aber schön. Habt ihr da Vorschläge für mich? Natürlich gilt wie immer: So günstig wie möglich, so teuer wie nötig.
 
Ok ich muss mittlerweile sagen, ich bin nicht mehr ganz glücklich mit meiner Umstellung, bzw. dem Wireguard Verhalten. Das war mit der OPNsense irgendwie anders. Der iOS Tunnel hat 90% der Zeit überhaupt keinen Traffic anliegen, außer, ich schicke einen Ping vom iPhone irgendwo hin oder mach die WG App kurz auf. Dann wird auch der Handshake Timer aktualisiert und ich seh einen kurzen Traffic Spike im Graph auf dem MT. Ansonsten ist der komplett flach und das iPhone ist wie ohne Internet. Fehlt da noch irgendwo was oder was ist da los?
 
Ich brauche mal wieder etwas Schwarmwissen. Habe heute definitiv zu viele Config-Dateien gelesen und komme hier gedanklich gerade auf keinen grünen Zweig 🙈

mlag_topology.png

Ich habe auf jeder "Seite" ein Paar Mikrotiks im MLAG laufen, die daran angeschlossenen Geräte funktionieren wie sie sollen. Ich schaffe aber gerade den Transfer nicht, wie ich die beiden Seiten untereinander verbinde... Habe ich in Gebäude 1 ein Bonding mit MLAG-IDs und in Gebäude 2 nur stumpf ein 802.3ad Bond ohne die IDs, sodass sich Gebäude 2 verhält wie ein Client oder gibt es dafür eine elegantere Lösung? Hat ggf mal jemand ein Config-Snippet, was ich mir anschauen könnte? Ich glaube das ist ganz einfach, aber manchmal sieht man den Wald vor lauter Bäumen nicht....
 
Ich meine, dass das mit Version 7.6 funktionierte . Danach war es eine Zeit lang kaputt.
Die MLAG-ID verbleibt im ICCP Link des jeweiligen Verbundes. Daher kann man das ganze gut speigeln.
 

Anhänge

  • mt-mlag.png
    mt-mlag.png
    55,4 KB · Aufrufe: 56
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh