18
DHCP vs. Redmi
Hallo alle zusammen,
vorab: ich bin zwar Entwickler, bin aber mit Netzwerkthemen nie richtig warm geworden. Ich bitte daher meine etwas rudimentären Kenntnisse zu entschuldigen. Zur eigentlichen Frage:
Ich nutze beruflich zur 2FA ein vom AG gestelltes Smartphone (Xiaomi Redmi 9A). Dieses Gerät hat immer große Probleme, sich wieder in das WLAN einzubuchen, wenn es einmal rausgeflogen ist. Für Internet/Telefonie sorgt eine Fritzbox 7590, dahinter ist per NAT ein Mikrotik hAP ac3 angebunden, der alles weitere übernimmt. Es werden mehrere virtuelle WLANs aufgespannt, jedes mit eigenem Adresspool, DHCP-Server etc.
Mir ist schon an mehreren Geräten in den verschiedenen WLANS aufgefallen, dass diese bei den DNS-Servern als Primäradresse die Gatewayadresse des jeweiligen Pools und als Sekundäradresse die Gatewayadresse der Fritzbox hinterlegt bekommen. Bei dem Redmi ist es so, dass als Gateway nur eine Adresse eingetragen wird. Leider nimmt das Redmi im DHCP-Modus nicht die Gatewayadresse des Pools, sondern die Gatewayadresse der Fritzbox und das Einbuchen schlägt fehl. Ändere ich am Redmi den Modus von DHCP auf statisch und hinterlege die Gatewayadresse des Pools sowie eine beliebige Adresse aus dem Pool als IP, klappt das einbuchen, er switcht automatisch auf DHCP zurück, die statische IP wird mit einer per DHCP vergebenen aus dem Pool überschrieben, als Gateway bleibt korrekt die Gatewayadresse des Pools eingetragen. Bei einem Windows-Notebook im selben WLAN wird von vornherein alles korrekt hinterlegt.
Mal abgesehen davon, dass die Implementierung des Redmi bestenfalls merkwürdig, schlimmstenfalls fehlerhaft arbeitet: Ich vermute, das durchreichen der Gatewayadresse der Fritzbox hängt mit der Einstellung "Use Peer DNS" bei den DHCP-Client-Einstellungen zusammen. Meine Frage wäre daher, ob das die Ursache sein kann und welche Konsequenzen es mit sich bringt, das abzuschalten.
VG
wimaflix
vorab: ich bin zwar Entwickler, bin aber mit Netzwerkthemen nie richtig warm geworden. Ich bitte daher meine etwas rudimentären Kenntnisse zu entschuldigen. Zur eigentlichen Frage:
Ich nutze beruflich zur 2FA ein vom AG gestelltes Smartphone (Xiaomi Redmi 9A). Dieses Gerät hat immer große Probleme, sich wieder in das WLAN einzubuchen, wenn es einmal rausgeflogen ist. Für Internet/Telefonie sorgt eine Fritzbox 7590, dahinter ist per NAT ein Mikrotik hAP ac3 angebunden, der alles weitere übernimmt. Es werden mehrere virtuelle WLANs aufgespannt, jedes mit eigenem Adresspool, DHCP-Server etc.
Mir ist schon an mehreren Geräten in den verschiedenen WLANS aufgefallen, dass diese bei den DNS-Servern als Primäradresse die Gatewayadresse des jeweiligen Pools und als Sekundäradresse die Gatewayadresse der Fritzbox hinterlegt bekommen. Bei dem Redmi ist es so, dass als Gateway nur eine Adresse eingetragen wird. Leider nimmt das Redmi im DHCP-Modus nicht die Gatewayadresse des Pools, sondern die Gatewayadresse der Fritzbox und das Einbuchen schlägt fehl. Ändere ich am Redmi den Modus von DHCP auf statisch und hinterlege die Gatewayadresse des Pools sowie eine beliebige Adresse aus dem Pool als IP, klappt das einbuchen, er switcht automatisch auf DHCP zurück, die statische IP wird mit einer per DHCP vergebenen aus dem Pool überschrieben, als Gateway bleibt korrekt die Gatewayadresse des Pools eingetragen. Bei einem Windows-Notebook im selben WLAN wird von vornherein alles korrekt hinterlegt.
Mal abgesehen davon, dass die Implementierung des Redmi bestenfalls merkwürdig, schlimmstenfalls fehlerhaft arbeitet: Ich vermute, das durchreichen der Gatewayadresse der Fritzbox hängt mit der Einstellung "Use Peer DNS" bei den DHCP-Client-Einstellungen zusammen. Meine Frage wäre daher, ob das die Ursache sein kann und welche Konsequenzen es mit sich bringt, das abzuschalten.
VG
wimaflix
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5715437732
Url: https://administrator.de/forum/dhcp-vs-redmi-5715437732.html
Ausgedruckt am: 28.12.2024 um 09:12 Uhr
18 Kommentare
Neuester Kommentar
dass diese bei den DNS-Servern als Primäradresse die Gatewayadresse des jeweiligen Pools und als Sekundäradresse die Gatewayadresse der Fritzbox hinterlegt bekommen
Das ist bei Mikrotik ganz normal wenn man den DHCP Server nicht entsprechend customized was bei dir im hAP vermutlich wohl der Fall ist. Leider machst du dazu keinerlei zielführende Angaben für eine zielführende Hilfe. 
Dein Miktrotik Koppelinterface zur FB arbeitet sehr wahscheinlich im DHCP Client Mode so das er dort den DNS Server per DHCP von der FB zieht. Kannst du selber unter IP -> DNS im WinBox Konfig Tool auf dem MT sehen.
Wenn der DHCP Server des MTs keinen DNS Server im DHCP Server Setup für das jeweilige IP Segment definiert hat, gibt er immer automatisch den global per DHCP Client Gelernten raus plus das jeweilige IP Interfaces des Segmentes. Der MT arbeitet im Default selber als DNS Caching Server. Daher propagiert er in dem Fall immer 2 DNS Server an die Clients in dem Segment.
Es gibt 2 Optionen das zu fixen:
- 1.) Das Koppelinterface nicht im DHCP Client Mode arbeiten zu lassen sondern mit einer statischen IP im FritzBox Netz außerhalb deren DHCP Pools zu betreiben (z.B. .178.254). Statische default Route dann auf die FB. Damit gibt der MT DHCP Server dann nur noch sich selber als einziger DNS Server mit der jeweiligen Segment IP aus. Logisch, denn er lernt ja dann keinen mehr per DHCP!
- 2.) Du trägst im Mikrotik DHCP Server Setup der jeweiligen IP Segmente immer dediziert einen DNS Server IP ein, also das DNS Server Feld nicht leer lassen. Damit wird der Automatismus das die Gateway IP und die per DHCP global gelernte DNS Adresse als DNS automatisch propagiert werden mit der dann statisch im DHCP Server vorgegebenen IP Adresse überschrieben und nur noch diese an die Clients propagiert.
Ob du dann die FB IP oder die IP des lokalen Segmentes einträgst ist eher kosmetisch. Letzters erspart dir überflüssigen DNS Traffic durch den Mikrotik weil der ja selber als DNS Caching Server agiert und Requests so immer lokal beantwortet.
Such dir die für dich Schönste raus...
Fazit:
Letztlich wohl ein Bug im Redmi, denn jedes Endgerät sollte mit multiplen DNS Servern problemlos umgehen können (Redundanz)
Und.... Handbuch lesen hilft ebenso!
https://wiki.mikrotik.com/wiki/Manual:IP/DHCP_Server
Ich bitte nochmal um Entschuldigung, wie gesagt, es fällt mir bei Netzwerkthemen immer schwer, das tatsächlich relevante herauszufiltern bzw. fühle ich mich bei der Fülle der Möglichkeiten des MikroTik trotz Handbuch immer etwas erschlagen...
Korrekt, der MikroTik hängt als DHCP-Client an der Fritzbox. Hatte ich auch im letzten Abschnitt angedeutet, hätte ich vielleicht klarer schreiben sollen. Bei den Adresspools ist immer nur das Gateway eingetragen, DNS leer. Ich werde hier mal deinen zweiten Tipp ausprobieren, danke dafür.
Korrekt, der MikroTik hängt als DHCP-Client an der Fritzbox. Hatte ich auch im letzten Abschnitt angedeutet, hätte ich vielleicht klarer schreiben sollen. Bei den Adresspools ist immer nur das Gateway eingetragen, DNS leer. Ich werde hier mal deinen zweiten Tipp ausprobieren, danke dafür.
Da musst du dich ja nicht entschuldigen! Um solche Themen zu klären ist ein Forum ja da. Mit der Fülle der Themen von Javascript, C#, oder was auch immer wird auch ein Netzwerker erschlagen wenn er damit konfrontiert wird. was dir als Entwickler vermutlich nur ein müdes Lächeln abringt. Die Welt ist ja bekanntlich immer relativ!! 😉
Das ist wohl wahr. Ich habe deinen Tipp ausprobiert und es funktioniert soweit ich gesehen habe alles so wie es soll. Das Redmi zickt zwar immer noch etwas (wechselt in den Status "gespeichert", was auch immer das genau bedeuten soll), bucht sich aber nach 1-2 Versuchen auch ohne Trick ein und das eingetragene GW ist korrekt. Danke nochmal.
Hallo aqui,
Bin neu in Forum bzw. schon lange aber Mitleser.
Erstmal vielen dank für das Tutorial.
Ich hätte da noch eine Frage bzw. Problem.
Wenn ich auf meine IP einen Portscan mache, sagt mit NMAP das Port 53 offen ist.
Soweit funktioniert meine Konfig auch. Aber meinen Fehler sehe ich grade nicht.
Die Allow-In Regeln habe ich weggelassen da, ich von außen nicht auf mein Netzwerk zugreifen möchte.
Als DNS Server kommt Pi-Hole zu Einsatz. Dieser ist in beiden Netzwerken vorhanden. (2 Geräte)
Hier die NMAP Ausgabe:
Gruß
wissens-hunger
Bin neu in Forum bzw. schon lange aber Mitleser.
Erstmal vielen dank für das Tutorial.
Ich hätte da noch eine Frage bzw. Problem.
Wenn ich auf meine IP einen Portscan mache, sagt mit NMAP das Port 53 offen ist.
Soweit funktioniert meine Konfig auch. Aber meinen Fehler sehe ich grade nicht.
ip dns server
!
access-list 101 permit ip 192.168.100.0 0.0.0.255 any
access-list 101 permit ip 192.168.101.0 0.0.0.255 any
!
zone security Internet
zone security Kabel
zone security WLAN
!
class-map type inspect match-any Router-Protocols-Erlaubt
match protocol tcp
match protocol udp
match protocol icmp
!
class-map type inspect match-any Kabel-Erlaubt
match protocol dns
match protocol http
match protocol https
match protocol pop3s
match protocol pop3
match protocol imaps
match protocol imap3
match protocol imap
match protocol smtp
match protocol rtsp
match protocol ftp
match protocol ftps
match protocol ssh
match protocol ntp
match protocol tftp
match protocol tcp
match protocol udp
match protocol icmp
!
class-map type inspect match-any WLAN-Erlaubt
match protocol dns
match protocol http
match protocol https
match protocol pop3s
match protocol pop3
match protocol imaps
match protocol imap3
match protocol imap
match protocol smtp
match protocol rtsp
match protocol ftp
match protocol ftps
match protocol ssh
match protocol ntp
match protocol tftp
match protocol tcp
match protocol udp
match protocol icmp
!
policy-map type inspect Router-WAN-Policy
description Traffic Router zum Internet
class type inspect Router-Protocols-Erlaubt
inspect
class class-default
drop
!
policy-map type inspect Kabel-Policy
description Traffic Kabel zum Internet
class type inspect Kabel-Erlaubt
inspect
class class-default
drop
!
zone-pair security Kabel-Internet source Kabel destination Internet
service-policy type inspect Kabel-Policy
!
zone-pair security WLAN-Internet source WLAN destination Internet
service-policy type inspect WLAN-PolicyDie Allow-In Regeln habe ich weggelassen da, ich von außen nicht auf mein Netzwerk zugreifen möchte.
Als DNS Server kommt Pi-Hole zu Einsatz. Dieser ist in beiden Netzwerken vorhanden. (2 Geräte)
Hier die NMAP Ausgabe:
Not shown: 999 closed tcp ports (reset)
PORT STATE SERVICE VERSION
53/tcp open domain Unbound 1.4.22
| dns-nsid:
| id.server: cisco-router-1
|_ bind.version: unbound 1.4.22
Aggressive OS guesses: Cisco 1841 router (IOS 12) (95%), Cisco 1841 router (IOS 12.4) (95%), Cisco 836, 890, 1751, 1841, 2800, or 2900 router (IOS 12.4 - 15.1) (95%), Cisco 860 or 870 router (IOS 12.4) (95%), Cisco C860, C880, or 2821 router (IOS 12.4 - 15.0) (95%), Cisco Aironet 1141N (IOS 12.4) or 3602I (IOS 15.3) WAP (95%), Cisco 1900-series router (IOS 15.4) (95%), Cisco 1921 router (IOS 15.1) (95%), Cisco Catalyst 3500-series switch (IOS 15.2) (95%), Cisco Aironet 2600-series WAP (IOS 15.2(2)) (95%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hopGruß
wissens-hunger
Hi @wissens-hunger
Willkommen im Forum! 🙂
Allerdings als erste Amtshandlung gleich einen Mikrotik Thread mit einer Cisco Frage kapern ist ja nicht die feine englische Art aber da du neu bist sei dir verziehen und @wimaflix wird deshalb und auch weil heute Sonntag ist sicher ein Auge zudrücken. 😉
Zurück zu deiner Frage...
Du hast zwar, wie du schreibst, das ZFW inbound Regelwerk weggelassen aber dennoch ist die ZFW Konfig, zumindestens so wie oben gezeigt, unvollständig, denn es fehlt vollständig das Zonen Pairing der Self Zone. (Siehe hier)
Es ist jetzt fraglich ob du das vergessen hast zu konfigurieren oder jetzt nur unvollständig deine Konfig hier gepostet hast. 🤔
Was leider auch fehlt ist die Information von WO aus du den Router mit nmap checkst?
Von innen über eins der lokalen Interfaces (vermutlich die Zonen Kabel und WLAN?!) ist das normal und auch so gewollt, denn mit dem Kommando "ip dns server" (sofern du das konfiguriert hast?!) aktivierst du den DNS Server auf dem Router.
Damit ist dann zumindestens auf den internen Interfaces der DNS Port TCP und UDP 53 erwartungsgemäß offen um DNS Anfragen der lokalen Clients beantworten zu können sofern du die Router IP als DNS Server an die Clients verteilst.
Vom Internet Interface allerdings sollte der Port aber durch die ZFW dicht sein und dann so ein Ergebnis zeigen:
Wenn du auch intern den Port 53 nicht offen haben möchtest musst du mit "no ip dns server" den lokalen DNS Server entfernen und dann im DHCP deinen Provider DNS an die lokalen Clients propagieren.
Willkommen im Forum! 🙂
Allerdings als erste Amtshandlung gleich einen Mikrotik Thread mit einer Cisco Frage kapern ist ja nicht die feine englische Art aber da du neu bist sei dir verziehen und @wimaflix wird deshalb und auch weil heute Sonntag ist sicher ein Auge zudrücken. 😉
Zurück zu deiner Frage...
Du hast zwar, wie du schreibst, das ZFW inbound Regelwerk weggelassen aber dennoch ist die ZFW Konfig, zumindestens so wie oben gezeigt, unvollständig, denn es fehlt vollständig das Zonen Pairing der Self Zone. (Siehe hier)
Es ist jetzt fraglich ob du das vergessen hast zu konfigurieren oder jetzt nur unvollständig deine Konfig hier gepostet hast. 🤔
Was leider auch fehlt ist die Information von WO aus du den Router mit nmap checkst?
Von innen über eins der lokalen Interfaces (vermutlich die Zonen Kabel und WLAN?!) ist das normal und auch so gewollt, denn mit dem Kommando "ip dns server" (sofern du das konfiguriert hast?!) aktivierst du den DNS Server auf dem Router.
Damit ist dann zumindestens auf den internen Interfaces der DNS Port TCP und UDP 53 erwartungsgemäß offen um DNS Anfragen der lokalen Clients beantworten zu können sofern du die Router IP als DNS Server an die Clients verteilst.
Vom Internet Interface allerdings sollte der Port aber durch die ZFW dicht sein und dann so ein Ergebnis zeigen:
admin@server:# nmap -p 53 80.1.2.3
Starting Nmap 7.40 ( https://nmap.org ) at 2023-01-29 17:13 CET
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 4.15 seconds
Hallo aqui,
Danke, für den Hinweis.
Hatte den falschen Tab offen. Sorry.
Geht jetzt hier weiter.
Gruß
wissens-hunger
Danke, für den Hinweis.
Hatte den falschen Tab offen. Sorry.
Geht jetzt hier weiter.
Gruß
wissens-hunger
Noch eine Verständnisfrage: Meine Firewall dropt eigentlich alles, was nicht explizit freigegeben ist. Wenn ich die IP des lokalen Segments als DNS Server IP eintrage, muss ich ja in der Input Chain UDP 53 für das Interface öffnen, welches dieses Segment nutzt, korrekt? Wäre es sinnvoll, bei Netzen, in denen keine lokale Namensauflösung stattfindet (weil deren Geräte nur ins Internet müssen und sich untereinander ohnehin nicht kennen), nur den DNS der Fritzbox einzutragen? Denn dann könnte ich für dieses Segment den Port geschlossen lassen. Oder mache ich einen Denkfehler?
UDP 53 für das Interface öffnen, welches dieses Segment nutzt, korrekt?
Nein, das ist nicht ganz korrekt. DNS benutzt bekanntlich UDP und TCP. Du musst also beide Protokollvarianten für DNS eintragen.nur den DNS der Fritzbox einzutragen?
Das ist eher eine kosmetische Frage. So muss dann halt jede DNS Anfrage durch den MT aber du kannst den Port in der input chain so dann dicht lassen, das ist richtig.
Ok, das habe ich gestern Abend so eingerichtet. Mir ist dabei leider ein kleiner Fauxpas unterlaufen, ich hatte vergessen, das per "in. Interface" zu beschränken. Somit war UDP/TCP 53 für einige Minuten auch von ether1 erreichbar, wo die Fritzbox dranhängt. Ich bin mir nun unsicher, was das sicherheitstechnisch bedeutet, UDP/TCP 53 sind ja auch an der Fritzbox offen.
Ich habe in den Logs des MT bislang nichts auffälliges gefunden, aber das muss ja nichts bedeuten. Nachdem das Notebook heute früh gleich mal in der Konsole gelandet ist, habe ich etwas beunruhigt dessen Logs gecheckt, aber sieht so aus, als hätte ihm das letzte Kernelupdate nicht gut bekommen.
Ich habe die Regel nun so umgesetzt, dass die entsprechenden Bridge-Interfaces einzeln zugelassen sind, evtl. switche ich das noch in "nicht-ether1" um, damit ich nicht so viele Regeln für ein und dasselbe setzen muss.
Ich habe in den Logs des MT bislang nichts auffälliges gefunden, aber das muss ja nichts bedeuten. Nachdem das Notebook heute früh gleich mal in der Konsole gelandet ist, habe ich etwas beunruhigt dessen Logs gecheckt, aber sieht so aus, als hätte ihm das letzte Kernelupdate nicht gut bekommen.
Ich habe die Regel nun so umgesetzt, dass die entsprechenden Bridge-Interfaces einzeln zugelassen sind, evtl. switche ich das noch in "nicht-ether1" um, damit ich nicht so viele Regeln für ein und dasselbe setzen muss.
UDP/TCP 53 sind ja auch an der Fritzbox offen.
Ja, auch die arbeitet als Caching DNS Server (wie fast alle einfachen Consumer Router).dass die entsprechenden Bridge-Interfaces einzeln zugelassen sind
IP Regeln kommen niemals auf die Bridge Member Interfaces. Logisch, denn eine Bridge arbeitet bekanntlich nur auf Layer 2. Sprich die "kennt" nur Hardware Mac Adressen aber keine IP Adressen weil eine einfache L2 Bridge diese Adressen nicht benötigt für ihre Forwarding Information. L3 IP Regeln bewirken hier also gar nichts weil sie schlicht ignoriert werden.IP Firewall Regeln werden immer mit ihren zugehörigen Chains global in der Firewall definiert! (Beispiel siehe hier).
Dann habe ich wohl das Konzept grundsätzlich falsch verstanden. Was ich gemacht hatte:
Ich habe Bridges für jedes Netz das ich haben wollte angelegt und diesen die benötigten Interfaces in der Portübersicht zugewiesen. Also z. B. Bridge "bridge-dzone" mit ether2, ether3", "bridge-wzone" mit "ether4". In der Firewall habe ich diese dann per "in. Interface" unterschieden. Sieht so aus:
Was du sagst, klingt schon einleuchtend, erstaunlicherweise funktioniert das hier trotzdem, wenn ich z. B. die regeln für UDP / TCP 17 deaktiviere, funktioniert bei der betroffenen Bridge die Namensauflösung nicht mehr.
Ich habe Bridges für jedes Netz das ich haben wollte angelegt und diesen die benötigten Interfaces in der Portübersicht zugewiesen. Also z. B. Bridge "bridge-dzone" mit ether2, ether3", "bridge-wzone" mit "ether4". In der Firewall habe ich diese dann per "in. Interface" unterschieden. Sieht so aus:
Was du sagst, klingt schon einleuchtend, erstaunlicherweise funktioniert das hier trotzdem, wenn ich z. B. die regeln für UDP / TCP 17 deaktiviere, funktioniert bei der betroffenen Bridge die Namensauflösung nicht mehr.
Ich habe Bridges für jedes Netz das ich haben wollte angelegt
Ist etwas "rumpelig" solche Lösung, per se aber nicht falsch. Das kann man so machen wenn man lediglich 2 oder 3 Netzsegmente hat und mehrere Ports im L2 zusammenfassen will. Skaliert aber sehr schlecht wenn es mehr IP Netze werden. Da ist das Design dann eher unglücklich. Best Practise und sehr viel eleganter löst du sowas immer mit VLANs beim Mikrotik:Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Mehr Netze werden es wahrscheinlich nicht werden, die Performance ist bislang auch in Ordnung. Ich denke trotzdem über die VLAN-Lösung nach, da ich evtl. noch einen zweiten MT anbinden und die Netze per tagged Port koppeln möchte. Ist aber Zukunftsmusik und da ich kein Netzwerker bin, bin ich mit dieser Lösung auch erstmal zufrieden. Die FW-Regeln sind aus deiner Sicht so akzeptabel? Hinter der jeweils ersten Regel bei input/fordward versteckt sich "established, related".
und die Netze per tagged Port koppeln möchte.
Spätestens dann brauchst du definitiv ein VLAN Setup! 😉Die FW-Regeln sind aus deiner Sicht so akzeptabel?
Jein!Du machst vermutlich einen Denkfehler, was bei Mikrotik aber auch leicht passieren kann.
Bei einer Firewall geht man ja üblicherweise von der Default Regel aus nach der sich alle Firewalls verhalten: Alles was nicht expliziert erlaubt ist, ist immer verboten. Also ein logisches Whitelisting Prinzip.
Die Mikrotik Logik ist aber eine klassische Router Logik wie sie grundsätzlich auch bei Cisco und anderen Herstellern auf Routern üblich ist. Ein Router erlaubt generell alles! Also ein logisches Blacklisting Prinzip.
Du hast jetzt vermutlich gedacht das die onboard FW sich wie eine richtig dedizierte FW verhält und alles was so oder so schon erlaubt ist (da ja generell erlaubt) nochmals erlaubt mit deinen Access Regeln. 2mal erlauben ist natürlich dann etwas nutzlos. Mit anderen Worten: Außer deinen DENY bzw. DROP Regeln greift keine einzige deiner FW Regeln.
Du musst also lediglich nur DENY Regeln erstellen für das was du NICHT willst. Alles andere ist ja per se erlaubt.
Dann verstehe ich aber nicht, wieso z. B. ohne Regel 4 die Namensauflösung in "bridge-ezone" nicht funktioniert. Ich war davon ausgegangen, dass die drop-Regel generell alles verbietet und ich die Ausnahmen davor definieren muss.
Das ist auch richtig. Allerdings gilt auch hier immer das Prinzip: "First match wins!" Sprich der erste positive Hit im Regelwerk einer Chain bedingt das der gesamte Rest nicht mehr abgearbeitet wird.
Vermutlich hast du dann ein Problem mit der Reihenfolge.
Vermutlich hast du dann ein Problem mit der Reihenfolge.
Na ja, wenn man beim vorherigen Beispiel bleibt, kann es ohne Regel 4 ja eigentlich nichts matchen. Wenn es nicht "established, related" matcht, kann es wenn es aus "bridge-ezone" kommt ja keine der Regeln außer 4 und 6 matchen, weil bei den anderen ein anderes "in. Interface" eingetragen ist. 4 und 6 matcht es auch nur, wenn Protokoll und Port passen, ansonsten dropt er es. So war jedenfalls meine Denke...
Ich seh schon, Netzwerke und ich werden in diesem Leben keine Freunde... :D
Ich seh schon, Netzwerke und ich werden in diesem Leben keine Freunde... :D
