7
Monowall: offene Ports trotz Rule .Vollsperrung.
Hallo zusammen.
ich habe ein Problem mit meiner Firewall. ich hoffe ihr könnt mir weiterhelfen.
Habe einen Igel Thin Client inder Bucht organisiert und eine zweite Lan Karte eingesetzt.
Alles läuft...bis auf eine Sache die mich sehr merkwürdig stimmt.
Wenn ich in den Firewallrules auf der LAN Seite alle Ports sperre (any), komme ich wie zu erwarten nicht mehr ins InterNetz.
Allerdings kann mein Handy, welches über ein AP direkt an der Lan Schnittstelle der Monowall hängt, via Whatsapp Nachrichten versenden.
Sehr kurios dachte ich mir und habe kurzer Hand einen Portscanner bemüht. Mit diesem habe ich testweise das WAN interface aus dem LAN Segment auf offene Ports gescannt.
Testweise nur bis Port 90. Und siehe da... es sind tatsächlich Ports offen obwohl ich eine komplette Sperrung als Rule definiert habe.
Wenn ich den Scanner länger laufen lasse über Port 90 hinweg werden entsprechend noch mehr offene Ports angezeigt.
Das ist wohl auch der Grund warum Whatsapp noch funktioniert
Das Setup:
WAN Router von ALice mit LAN 192.168.2.1.
Dieser arbeitet noch als DHCP da ich aus irgendeinem Grund keine statische Adresse in der Mono vergeben kann ohne dass es zu Verbindungsproblemen kommt.
Daran dann die Mono.
WAN:DHCP client
LAN 192.168.1.1-------> AP Linksys WRT54GL (ohne Routing WLAN und LAN durchgebridged)
Gateway: 192.168.2.1
DNS: 192.168.2.1
DHCP SUBnet: 192.168.1.0/24
DHCP Range : 192.168.1.100 - 200
Ömmmm...
Wie denn das?
Wäre super wennn wir das mal zusammen weiter ergründen könnten.
Ich möchte nämlich auch solche Messengerdienste wie Whatsapp für meinen baldigen Hotspot sperren.
Vielen Dank schon mal...........
ich habe ein Problem mit meiner Firewall. ich hoffe ihr könnt mir weiterhelfen.
Habe einen Igel Thin Client inder Bucht organisiert und eine zweite Lan Karte eingesetzt.
Alles läuft...bis auf eine Sache die mich sehr merkwürdig stimmt.
Wenn ich in den Firewallrules auf der LAN Seite alle Ports sperre (any), komme ich wie zu erwarten nicht mehr ins InterNetz.
Allerdings kann mein Handy, welches über ein AP direkt an der Lan Schnittstelle der Monowall hängt, via Whatsapp Nachrichten versenden.
Sehr kurios dachte ich mir und habe kurzer Hand einen Portscanner bemüht. Mit diesem habe ich testweise das WAN interface aus dem LAN Segment auf offene Ports gescannt.
Testweise nur bis Port 90. Und siehe da... es sind tatsächlich Ports offen obwohl ich eine komplette Sperrung als Rule definiert habe.
Wenn ich den Scanner länger laufen lasse über Port 90 hinweg werden entsprechend noch mehr offene Ports angezeigt.
Das ist wohl auch der Grund warum Whatsapp noch funktioniert
Das Setup:
WAN Router von ALice mit LAN 192.168.2.1.
Dieser arbeitet noch als DHCP da ich aus irgendeinem Grund keine statische Adresse in der Mono vergeben kann ohne dass es zu Verbindungsproblemen kommt.
Daran dann die Mono.
WAN:DHCP client
LAN 192.168.1.1-------> AP Linksys WRT54GL (ohne Routing WLAN und LAN durchgebridged)
Gateway: 192.168.2.1
DNS: 192.168.2.1
DHCP SUBnet: 192.168.1.0/24
DHCP Range : 192.168.1.100 - 200
Ömmmm...
Wie denn das?Wäre super wennn wir das mal zusammen weiter ergründen könnten.
Ich möchte nämlich auch solche Messengerdienste wie Whatsapp für meinen baldigen Hotspot sperren.
Vielen Dank schon mal...........
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 215067
Url: https://administrator.de/contentid/215067
Printed on: April 26, 2024 at 21:04 o'clock
7 Comments
Latest comment
Diese "Deny any any" Rule am LAN Port ist eigentlich Blödsinn, denn das ist der Default wenn du keine Regel am Port einstellst ! Überlicher Standard bei Firewalls.
In sofern ist diese Regel doppelt gemoppelt und überflüssiger Unsinn.
Was immer geht ist die IP Adresse des LAN Ports zu connecten (Anti Lockout Rule), aber auch die Regel ist abschaltbar so das wirklich nur genau das gilt was du in der Regel für den Zugriff eingestellt hat.
Beim deaktivieren der Anti Lockout Rule muss man aber aufpassen das man keinen Fehler macht, denn sonnst hilft oft nur der Zugriff über das Terminal die FW wieder zu aktivieren.
Es kann niemals sein das bei dieser Regel (oder wenn du sie komplett weglassen würdest) einzelne Geräte in dem Segment durch die FW kommen. Das wäre barer Unsinn und würde ja die Firewall per se konterkarieren.
zu 100% liegt dann ein Verkabelungsfehler vor.
Außerdem könntest du das ganz leicht in der Session Tabelle nachsehen unter "Diagnostics" denn dort müssten die inbound und outbound Sessions dieser Verbindung aufgelistet sein, was dann eine aktive Verbindung über die Firewall anzeigt.
Vermutlich gehst du also außen irgendwie um die Firewall rum ?!
Ebenso ist das Scannen des WAN Ports aus dem LAN ebenso totaler Unsinn, denn es können nur solche Scans durchgehen die die FW LAN Regel inbound erlaubt.
Ausserdem rennst du in ein Hairpin NAT Problem bei dieser Vorgehensweise:
http://wiki.mikrotik.com/wiki/Hairpin_NAT
Lies die die Paketwalk "Steps" durch dann weisst du warum sowas sinnfrei ist ! Man kann das Hairpinning abschalten in den Advanced Settings solltest du aber definitiv nicht machen da das andere problem nach sich zieht !
Auch das alles lässt ganz klar darauf schliessen das es irgendwo eine Ethernet verbindung um die Firewall rum gibt bei dir !
Das du keine statische IP Konfiguration auf der Monowall vergeben kannst sollte dir ebenso zu denken geben. Das zeigt das die HW defekt ist oder nicht richtig erkannt wurde, denn das ist natürlich problemlos möglich und in deinem Szenario auch sehr sinnvoll.
Wichtig ist in einer Kaskade mit einem Router das das Blocken der RFC 1918 IP Adressen am WAN Port deaktiviert ist !! (Haken entfernen) und...
Das die der davorliegende Router als DNS Server statisch definiert ist, denn sonst funktioniert kein DNS in der FW !
Vermutlich alles Dinge die du vergessen und nicht beachtet hast.
Halte dich an diese Tutorial und die darauffolgenden Threads, dort ist das alles erklärt:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
und auch
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
In sofern ist diese Regel doppelt gemoppelt und überflüssiger Unsinn.
Was immer geht ist die IP Adresse des LAN Ports zu connecten (Anti Lockout Rule), aber auch die Regel ist abschaltbar so das wirklich nur genau das gilt was du in der Regel für den Zugriff eingestellt hat.
Beim deaktivieren der Anti Lockout Rule muss man aber aufpassen das man keinen Fehler macht, denn sonnst hilft oft nur der Zugriff über das Terminal die FW wieder zu aktivieren.
Es kann niemals sein das bei dieser Regel (oder wenn du sie komplett weglassen würdest) einzelne Geräte in dem Segment durch die FW kommen. Das wäre barer Unsinn und würde ja die Firewall per se konterkarieren.
zu 100% liegt dann ein Verkabelungsfehler vor.
Außerdem könntest du das ganz leicht in der Session Tabelle nachsehen unter "Diagnostics" denn dort müssten die inbound und outbound Sessions dieser Verbindung aufgelistet sein, was dann eine aktive Verbindung über die Firewall anzeigt.
Vermutlich gehst du also außen irgendwie um die Firewall rum ?!
Ebenso ist das Scannen des WAN Ports aus dem LAN ebenso totaler Unsinn, denn es können nur solche Scans durchgehen die die FW LAN Regel inbound erlaubt.
Ausserdem rennst du in ein Hairpin NAT Problem bei dieser Vorgehensweise:
http://wiki.mikrotik.com/wiki/Hairpin_NAT
Lies die die Paketwalk "Steps" durch dann weisst du warum sowas sinnfrei ist ! Man kann das Hairpinning abschalten in den Advanced Settings solltest du aber definitiv nicht machen da das andere problem nach sich zieht !
Auch das alles lässt ganz klar darauf schliessen das es irgendwo eine Ethernet verbindung um die Firewall rum gibt bei dir !
Das du keine statische IP Konfiguration auf der Monowall vergeben kannst sollte dir ebenso zu denken geben. Das zeigt das die HW defekt ist oder nicht richtig erkannt wurde, denn das ist natürlich problemlos möglich und in deinem Szenario auch sehr sinnvoll.
Wichtig ist in einer Kaskade mit einem Router das das Blocken der RFC 1918 IP Adressen am WAN Port deaktiviert ist !! (Haken entfernen) und...
Das die der davorliegende Router als DNS Server statisch definiert ist, denn sonst funktioniert kein DNS in der FW !
Vermutlich alles Dinge die du vergessen und nicht beachtet hast.
Halte dich an diese Tutorial und die darauffolgenden Threads, dort ist das alles erklärt:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
und auch
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
1
Vielen Dank für die wirklich fixe Antwort.
An die Tuts habe ich mich gehalten. Es finktioniert auch alles soweit. Auch das CP wunderbar. Bis auf diese beiden Sachen
Verkabelungsfehler kann ich soweit ausschließen.
Alice Modem LAN<----->WAN -Monowall-LAN<----> LAN Accesspoint. Und mein Laptop ist via Wlan am AP.
Du sprichst ein evtl Hardware Problem an. Evtl liegt es wirklich daran. Denn die Settings sind für eine statische Adressvergabe auf der Wan Seite korrekt. Und dennoch kommt es zu einem DNS Problem scheinbar.
Das erste was ich nun teste ist eine andere Netzwerkkarte.
An die Tuts habe ich mich gehalten. Es finktioniert auch alles soweit. Auch das CP wunderbar. Bis auf diese beiden Sachen
Verkabelungsfehler kann ich soweit ausschließen.
Alice Modem LAN<----->WAN -Monowall-LAN<----> LAN Accesspoint. Und mein Laptop ist via Wlan am AP.
Du sprichst ein evtl Hardware Problem an. Evtl liegt es wirklich daran. Denn die Settings sind für eine statische Adressvergabe auf der Wan Seite korrekt. Und dennoch kommt es zu einem DNS Problem scheinbar.
Das erste was ich nun teste ist eine andere Netzwerkkarte.
Du schreibts oben "Alice Modem LAN" !!!
Ist das wirklich ein reines Modem ?? Oder hast du mal wieder wie viele Anfänger hier laienhaft den Begriff Modem und Router durcheienadergewürfelt ??
Ein Modem ist ein passiver medienwandler von Ethernet auf DSL Frames. Dazu müsstest du dann PPPoE an der Monowall WAN Port definiert haben und deine Provider Zugangsdaten dort konfiguriert haben.
Die Monowall hält dann die öffentliche Provider IP !
Oder ist es ein Router. Also routet der mit NAT Firewall schon das Providernetz auf dein privates LAN. Sprich du hast letztlich eine Router Kaskade mit Router und Monowall wie sie hier in der "Alternative 3" beschrieben ist ??
Da solltest du also etwas präziser sein in deiner Beschreibung, denn ganu DAS könnte den Bypass bewirken den du so vehement abstreitest !!
Oder dein Laptop bucht sich in das WLAN des "Modem/Routers" ein und bypasst die MW so.
Benutzt du eine einzigartige SSID (WLAN Name) für den AP am LAN Port der Monowall ??
Das mit dem DNS Problem ist klar bei statischen IP Adressen. Du hast wie vermutlich die meisten Leute hier die mit statischen IP Adressen arbeiten vergessen den DNS Server auch statisch bei der Monowall zu konfigurieren. Das ist ein typischer Anfängerfehler, obwohl du es oben mit der .2.1 richtig gemacht hast.
Der DHCP Server der MW (wenn sie bei dir am LAN Port DHCP macht) gibt dann keine oder die falsche DHCP Adresse raus und dann schlägt der DNS Requests von Endgeräten fehl, da die MW per default DNS Proxy ist und ohne DNS Eintrag natürlich nicht funktioniert wenn der nicht dynamsich kommt...logo !
Trag das also nach (Wenn die Alice Box denn wirklich als Router rennt und NICHT als Modem) dann funktioniert auch DNS mit static IPs wunderbar !
Achte natürlich darauf das die MW IP nicht gerade im DHCP Scope des Routers liegt. Es empfiehlt sich was "ganz oben" zu nehmen wie die .254 !
Sowas wie die .132 ist kontraproduktiv für Router und Gateways. Wenn die "mittendrin" liegen wie deine .132 gibt es oft Fehler mit Doppelvergabe usw.
Sinn macht den DHCP Scope auf der Alice Gurke entsprechend zu überprüfen.
Eigentlich kann es nicht an der Karte leigen, denn die ist richtig erkannt worden, was du an der Mac Adresse ja sehen kannst ?
Tip: Flash dir mal ein pfSense auf die Maschine. pfSense ist die Schwester der Monowall hat aber modernere Treiber und ein größeres Spektrum.
So oder so wird es aber daran nicht liegen, den die HW sagt was anderes. Du hast irgendwo einen IP Bypass gesteckt oder versehentlich konfiguriert !
Ist das wirklich ein reines Modem ?? Oder hast du mal wieder wie viele Anfänger hier laienhaft den Begriff Modem und Router durcheienadergewürfelt ??
Ein Modem ist ein passiver medienwandler von Ethernet auf DSL Frames. Dazu müsstest du dann PPPoE an der Monowall WAN Port definiert haben und deine Provider Zugangsdaten dort konfiguriert haben.
Die Monowall hält dann die öffentliche Provider IP !
Oder ist es ein Router. Also routet der mit NAT Firewall schon das Providernetz auf dein privates LAN. Sprich du hast letztlich eine Router Kaskade mit Router und Monowall wie sie hier in der "Alternative 3" beschrieben ist ??
Da solltest du also etwas präziser sein in deiner Beschreibung, denn ganu DAS könnte den Bypass bewirken den du so vehement abstreitest !!
Oder dein Laptop bucht sich in das WLAN des "Modem/Routers" ein und bypasst die MW so.
Benutzt du eine einzigartige SSID (WLAN Name) für den AP am LAN Port der Monowall ??
Das mit dem DNS Problem ist klar bei statischen IP Adressen. Du hast wie vermutlich die meisten Leute hier die mit statischen IP Adressen arbeiten vergessen den DNS Server auch statisch bei der Monowall zu konfigurieren. Das ist ein typischer Anfängerfehler, obwohl du es oben mit der .2.1 richtig gemacht hast.
Der DHCP Server der MW (wenn sie bei dir am LAN Port DHCP macht) gibt dann keine oder die falsche DHCP Adresse raus und dann schlägt der DNS Requests von Endgeräten fehl, da die MW per default DNS Proxy ist und ohne DNS Eintrag natürlich nicht funktioniert wenn der nicht dynamsich kommt...logo !
Trag das also nach (Wenn die Alice Box denn wirklich als Router rennt und NICHT als Modem) dann funktioniert auch DNS mit static IPs wunderbar !
Achte natürlich darauf das die MW IP nicht gerade im DHCP Scope des Routers liegt. Es empfiehlt sich was "ganz oben" zu nehmen wie die .254 !
Sowas wie die .132 ist kontraproduktiv für Router und Gateways. Wenn die "mittendrin" liegen wie deine .132 gibt es oft Fehler mit Doppelvergabe usw.
Sinn macht den DHCP Scope auf der Alice Gurke entsprechend zu überprüfen.
Eigentlich kann es nicht an der Karte leigen, denn die ist richtig erkannt worden, was du an der Mac Adresse ja sehen kannst ?
Tip: Flash dir mal ein pfSense auf die Maschine. pfSense ist die Schwester der Monowall hat aber modernere Treiber und ein größeres Spektrum.
So oder so wird es aber daran nicht liegen, den die HW sagt was anderes. Du hast irgendwo einen IP Bypass gesteckt oder versehentlich konfiguriert !
Hallöchen..
Ja korrekt. es handelt sich um ein Modemrouter der das PPPoE komplett übernimmt. Sorry für diese Verwirrung.
Mal kurz zu meiner Vorghehensweise. Ich habe die CF Karte nochmal komplet neu geflasht mit der Mono 1.34. Zur Sicherheit habe ich eine neue Ethernetkarte eingebaut, die auch in der Liste der kompatiblen Geräten steht. Zudem habe ich bei der "Erstconfig" an der Console die Interfaces getauscht. Also die Onboard NIC war vorher WAN und nun bedient sie das LAN Segment.
Aus irgendeinem Grund funktioniert die vergabe der statischen IP nun wunderbar an der WAN Seite in der Mono.
Es gibt keine DNS Probleme mehr.
Die Unterschiede sind wie gesagt: neue NIC, LAN WAN Segment gedreht und diesmal keine statische Route in der Monowall definiert. (funktioniert auch ohne?!)
Nun schon mal alles bestens...
Aber das Problem mit den offenen Ports besteht weiterhin. Ohne BYpass gesteckt oder via Wlan.
Ich scanne die Ports und es werden wieder offene Durchgänge angezeigt. Wenn ich Freigaben in den Rules angebe werden diese nach einem erneuten Scan auch als offen angezeigt. Wenn ich die Rule rausnehme sind diese auch wieder geschlossen. Aber es bleiben die anderen offenen.
Ach ja...Whatsapp funktioniert auch grrrrrr...
Edit.
In den Firewall States wird der Connect auf den Whatsapp Server angezeigt. 50.22.231.41 ist der Server.
Die Pakete rauschen so durch......
Edit zum zweiten...
Nachdem ich die Firewallstates resettet habe scheint das Problem nicht mehr zu bestehen. Nun blockt die Firewall den Connect. Whatsapp funktioniert nicht mehr.
Da stellt sich mir die Frage ob man bei einer Änderung der Rules die States tables resetten muss.?
Ja korrekt. es handelt sich um ein Modemrouter der das PPPoE komplett übernimmt. Sorry für diese Verwirrung.
Mal kurz zu meiner Vorghehensweise. Ich habe die CF Karte nochmal komplet neu geflasht mit der Mono 1.34. Zur Sicherheit habe ich eine neue Ethernetkarte eingebaut, die auch in der Liste der kompatiblen Geräten steht. Zudem habe ich bei der "Erstconfig" an der Console die Interfaces getauscht. Also die Onboard NIC war vorher WAN und nun bedient sie das LAN Segment.
Aus irgendeinem Grund funktioniert die vergabe der statischen IP nun wunderbar an der WAN Seite in der Mono.
Es gibt keine DNS Probleme mehr.
Die Unterschiede sind wie gesagt: neue NIC, LAN WAN Segment gedreht und diesmal keine statische Route in der Monowall definiert. (funktioniert auch ohne?!)
Nun schon mal alles bestens...
Aber das Problem mit den offenen Ports besteht weiterhin. Ohne BYpass gesteckt oder via Wlan.
Ich scanne die Ports und es werden wieder offene Durchgänge angezeigt. Wenn ich Freigaben in den Rules angebe werden diese nach einem erneuten Scan auch als offen angezeigt. Wenn ich die Rule rausnehme sind diese auch wieder geschlossen. Aber es bleiben die anderen offenen.
Ach ja...Whatsapp funktioniert auch grrrrrr...
Edit.
In den Firewall States wird der Connect auf den Whatsapp Server angezeigt. 50.22.231.41 ist der Server.
Die Pakete rauschen so durch......
Edit zum zweiten...
Nachdem ich die Firewallstates resettet habe scheint das Problem nicht mehr zu bestehen. Nun blockt die Firewall den Connect. Whatsapp funktioniert nicht mehr.
Da stellt sich mir die Frage ob man bei einer Änderung der Rules die States tables resetten muss.?
Irgendwas machst du grundlegend noch falsch !
1. Frage: Welchen FW Port scannst du auf offene Ports LAN oder WAN ??
2. Frage: Welche Ports sind denn offen ??
"Die Pakete rauschen so durch......"
Das ist in einer Default Konfig auch richtig, denn auf dem LAN Port gibt es eine Default Firewall Rule die aus dem LAN Netzwerwerk Segement mit any zu any alles erlaubt !!
Diese Regel müsste man natürlich löschen und entsprechend anpassen !!!
Und nein, die States Tabel muss man NICHT resetten !
Sowie du die Regeln änderst und auf "Apply" klickst, sie also aktivierst in der FW werden die nach ca. 2 -3 Sekunden aktiv ! Aaaaber....bestehende, aktive TCP Sessions in der FW timen erst relativ langsam aus wenn du die FW Regeln während einer aktiven Session änderst !!
Das ist von den TCP Timern abhängig. Es mag also sein das aktive Sessions erst nach 2-3 Minuten unterbrochen werden oder...wenn man natürlich die aktive Sessiontable in der FW resettet wie du es gemacht hast !
Also mit anderen Worten funktioniert nun alles wie es soll oder wie ?!
1. Frage: Welchen FW Port scannst du auf offene Ports LAN oder WAN ??
2. Frage: Welche Ports sind denn offen ??
"Die Pakete rauschen so durch......"
Das ist in einer Default Konfig auch richtig, denn auf dem LAN Port gibt es eine Default Firewall Rule die aus dem LAN Netzwerwerk Segement mit any zu any alles erlaubt !!
Diese Regel müsste man natürlich löschen und entsprechend anpassen !!!
Und nein, die States Tabel muss man NICHT resetten !
Sowie du die Regeln änderst und auf "Apply" klickst, sie also aktivierst in der FW werden die nach ca. 2 -3 Sekunden aktiv ! Aaaaber....bestehende, aktive TCP Sessions in der FW timen erst relativ langsam aus wenn du die FW Regeln während einer aktiven Session änderst !!
Das ist von den TCP Timern abhängig. Es mag also sein das aktive Sessions erst nach 2-3 Minuten unterbrochen werden oder...wenn man natürlich die aktive Sessiontable in der FW resettet wie du es gemacht hast !
Also mit anderen Worten funktioniert nun alles wie es soll oder wie ?!
Hallo.
habe das WAN Interface auf offene Ports gescannt. (Aus dem Lan Segment heraus also durch die Firewall)
ich vermute mittlerweile, dass es an dem Portscanner (LamaCreation Portscanner) liegt.
Werde nun nochmal einen ausführlichen Portscan machen und den Screenshot mal einstellen.
Das Whatsapp Problem ist mit dem Reset er statetables endgültig vom Tisch. Interessant wie lange die Timings sind bei diesem Messenger.
Vermute die machen das absichtlich so falls es Probleme mit der mobilen Verbindung mit dem Handy gibt.
Melde mich sobald der Scan durchgelaufen ist.
Edit : Alles dicht!! Perfect!
Es lag scheinbar alles an den statetables.
Ich sage vielen Dank für den netten Support!!!!
habe das WAN Interface auf offene Ports gescannt. (Aus dem Lan Segment heraus also durch die Firewall)
ich vermute mittlerweile, dass es an dem Portscanner (LamaCreation Portscanner) liegt.
Werde nun nochmal einen ausführlichen Portscan machen und den Screenshot mal einstellen.
Das Whatsapp Problem ist mit dem Reset er statetables endgültig vom Tisch. Interessant wie lange die Timings sind bei diesem Messenger.
Vermute die machen das absichtlich so falls es Probleme mit der mobilen Verbindung mit dem Handy gibt.
Melde mich sobald der Scan durchgelaufen ist.
Edit : Alles dicht!! Perfect!
Es lag scheinbar alles an den statetables.
Ich sage vielen Dank für den netten Support!!!!
Ist auch klar, denn wenn es aktive Sessions über die FW gibt sind diese Ports für die Session natürlich offen...logisch !
Gut wenn nun alles klappt wie es soll !
Gut wenn nun alles klappt wie es soll !