Hallo, könnt ihr mir helfen einen Logeintrag korrekt zu deuten?
DROP: NewStateWithoutSyn > 78.46.5.205:110 > eth0 > 192.168.178.2:48138 > TCP. Dasselbe mit ":995".
ich stelle heute erstmals fest- wobei dies durchaus schon länger stattfinden kann- dass die RC200 Pakete verwirft. Ich verstehe dies so dass Pakete über port 110 bzw 995 an eth0 ankommen.
Die IP 78.46.5.205 gehört meinem Provider/ Domainserver, "gehört also zu meinem Mailsystem".
Wie ist dies nun zu deuten, wessen POP-Anfrage wird abgewiesen? Ich bin der Meinung der fremde Server klopft an der RC200 an um mails zu holen.
Ich setze den mail connector ein um die Benutzermailboxen auf dem externen Server abzufragen, dies funktioniert seit Jahren "ohne Verlust", ich vermisse keine emails.
Kann mir jemand weiterhelfen oder muss ich die Ports erstmal freigeben um zu sehen wohin geroutet wird?
Gruss Hubert
Logeintrag verstehen: port 110/995, drop
Moderator: Securepoint
Hallo Hubert,
das habe ich auch bei einigen Kunden - dürfte mit dem Mailkonnektor zusammenhängen, da es bei mir in im Mailkonnektor eingestellten Intervallen auftritt - interessanterweise aber nicht immer mit derselben Anzahl (nämlich der abzurufenden Postfächer).
Mails werden allerdings trotzdem abgerufen. Ich hab es mal als Bug des Servers ad acta gelegt, da 1. alles funktioniert wie erwünscht und 2. es nicht bei allen Servern vorkommt (der "alte" Server des selben Providers macht das z.B. nicht)
Also eigentlich macht ein POP-Server keine Anfragen, der wartet im Normalfall nur auf eingehende Verbindungen, die er beantwortet - einzige mir bekannte Ausnahme ist ETRN bzw. ATRN - wobei selbst hierbei die Verbindung externer Server -> Firewall glaube ich über SMTP - also andere als die genannten Ports läuft.
Also etwas salopp formuliert würde ich es aufgrund des Logeintrags so ausdrücken: Der Server will nochwas mitteilen, nachdem die FW die Verbindung als beendet ansieht - Verbindung beenden kann entweder der Server, Client oder ein Timeout auf der FW - der Server wird sie nicht beenden, wenn er noch plaudern will - der Client beendet sie erst wenn alles erledigt ist - Timeout habe ich noch nicht getestet, wirds aber denke ich eher nicht sein. Von daher nicht perfekt aber erträglich
LG
das habe ich auch bei einigen Kunden - dürfte mit dem Mailkonnektor zusammenhängen, da es bei mir in im Mailkonnektor eingestellten Intervallen auftritt - interessanterweise aber nicht immer mit derselben Anzahl (nämlich der abzurufenden Postfächer).
Mails werden allerdings trotzdem abgerufen. Ich hab es mal als Bug des Servers ad acta gelegt, da 1. alles funktioniert wie erwünscht und 2. es nicht bei allen Servern vorkommt (der "alte" Server des selben Providers macht das z.B. nicht)
Also eigentlich macht ein POP-Server keine Anfragen, der wartet im Normalfall nur auf eingehende Verbindungen, die er beantwortet - einzige mir bekannte Ausnahme ist ETRN bzw. ATRN - wobei selbst hierbei die Verbindung externer Server -> Firewall glaube ich über SMTP - also andere als die genannten Ports läuft.
Also etwas salopp formuliert würde ich es aufgrund des Logeintrags so ausdrücken: Der Server will nochwas mitteilen, nachdem die FW die Verbindung als beendet ansieht - Verbindung beenden kann entweder der Server, Client oder ein Timeout auf der FW - der Server wird sie nicht beenden, wenn er noch plaudern will - der Client beendet sie erst wenn alles erledigt ist - Timeout habe ich noch nicht getestet, wirds aber denke ich eher nicht sein. Von daher nicht perfekt aber erträglich
LG
Hallo HP, danke für deine "Bestätigung". Tatsächlich stimmen die Zeiten und Intervalle des drops mit den Abrufen des mail connectors überein.
Dieser Vorgang schadet wohl niemandem, da ich aber alle Beteiligten Geräte kenne würde ich ihn doch lieber abstellen.
Hierzu habe ich mit einer Regel ein wenig gespielt, allerdings ohne Erfolg:
Quelle: 78.46.5.205/32
Ziel: internal networks/ bzw. internal-interface/ bzw. external interface
Dienst: 110 bzw 995 bzw any
NAT: DestNat, external-interface, Dienst 110/ 995/ any
Ob nun meine Regeln einen Fehler enthielten (ich die richtige Regel nicht gefunden habe) oder hier nie ein Routing stattfinden wird sei dahingestellt.
Ich lasse das "Problem" für den Moment ebenfalls so stehen; evtl. findet ja mal jemand eine Lösung, es zeigen ja bereits mehrere Server dasselbe Verhalten.
Danke für deine Beratung, Gruß Hubert
Dieser Vorgang schadet wohl niemandem, da ich aber alle Beteiligten Geräte kenne würde ich ihn doch lieber abstellen.
Hierzu habe ich mit einer Regel ein wenig gespielt, allerdings ohne Erfolg:
Quelle: 78.46.5.205/32
Ziel: internal networks/ bzw. internal-interface/ bzw. external interface
Dienst: 110 bzw 995 bzw any
NAT: DestNat, external-interface, Dienst 110/ 995/ any
Ob nun meine Regeln einen Fehler enthielten (ich die richtige Regel nicht gefunden habe) oder hier nie ein Routing stattfinden wird sei dahingestellt.
Ich lasse das "Problem" für den Moment ebenfalls so stehen; evtl. findet ja mal jemand eine Lösung, es zeigen ja bereits mehrere Server dasselbe Verhalten.
Danke für deine Beratung, Gruß Hubert
-
Christian E.
- Securepoint
- Beiträge: 238
- Registriert: Do 05.07.2012, 16:19
- Wohnort: Lüneburg
Hallo zusammen,
das Paket wird von der Firewall gedropt, da es ein ungültiges TCP-Flag enthält, nämlich NewStateWithoutSyn.
Da das Paket von dem Provider/Mailserver kommt und mit dem Port antwortet, der angesprochen wurde: 78.46.5.205:110 > eth0 > 192.168.178.2:48138 handelt sich
um ein Antwortpaket. Die Firewall hat aber die Verbindung schon beendet und verwirft das Paket. Die Firewall würde nämlich zunächst ein SYN Paket erwarten.
Unter Anwendungen -> IDS/IPS lässt sich der Drop von ungültigen TCP-Flag deaktivieren.
Gruß
Christian
das Paket wird von der Firewall gedropt, da es ein ungültiges TCP-Flag enthält, nämlich NewStateWithoutSyn.
Da das Paket von dem Provider/Mailserver kommt und mit dem Port antwortet, der angesprochen wurde: 78.46.5.205:110 > eth0 > 192.168.178.2:48138 handelt sich
um ein Antwortpaket. Die Firewall hat aber die Verbindung schon beendet und verwirft das Paket. Die Firewall würde nämlich zunächst ein SYN Paket erwarten.
Unter Anwendungen -> IDS/IPS lässt sich der Drop von ungültigen TCP-Flag deaktivieren.
Gruß
Christian