Fortigate 50B lässt keine Verbindung vom Telekom-Fallback-Server zu
Mahlzeit!
Wir haben seit 13.01. ein Problem mit der Zustellbarkeit der Mails die an uns gesendet werden.
Die Mails werden an uns gesendet, die Fortigate hat im Traffic-Log den Verbindungsversuch drinnen und schreibt nach zwei erfolgreichen Verbindungen eine "deny" Meldung rein und als Fehlernachricht steht "no session matched".
Das lustige daran: Das passiert nicht bei allen Mails - aber auch nicht nur bei bestimmten. Wir haben Kunden / Lieferanten von Deutschland, Slowenien und Österreich wo wir dieses Problem haben...
Nochmals Mahlzeit.
Nun ein bisschen ausführlicher:
Aufgefallen ist die Thematik am 17.01. weil mein Chef meinte er warte auf ein E-Mail von einem Kunden das bis jetzt noch nicht angekommen ist. Eine Kollegin meinte dann "ja, ich warte auch auf ein Mail" daraufhin bin ich stutzig geworden und habe die Logs der Firewall durchsucht - aber nichts gefunden. Dachte zuerst natürlich an den Spam-Filter und habe die betreffenden Mail-Adressen auf die Whitelist gesetzt - hat aber nichts gebracht. Dann habe ich noch die SMTP Server vom Absender auf die Whitelist gesetzt - hat auch nichts gebracht, die IP Adresse des Telekom Servers auf die Whitelist > kein Erfolg. Das komplette UTM Profil neu angelegt - keine manuellen Spam-Filter hinterlegt, jeglichen Internetverkehr "verboten" (Internetradios,... wohlgemerkt nicht in der Firwall verboten, sondern per interner Mail an die Leute geschickt) Firewall neu gestartet, Firmware aktualisiert, unzählige Stunden mit der Telekom-Hotline verbracht (bzgl. der Unzustellbarkeit der Nachrichten die bei denen im Fallback liegen). Jetzt hatte ich gestern nochmal einen Techniker von unserem EDV-Systemhaus hier und der meinte auch nur "Firewall ist richtig konfiguriert, passt soweit alles. Einziges der Upload von 0,3mbit ist schlecht". Heute hatte ich einen Upload von 0,1 - 0,2 mbit. (gemessen mit speedtest.net und speedmeter.de auf dem Salzburger Server).
Am Exchange kann es nicht liegen, da ich die Mail gar nicht mal bei der Fortigate durch bekomme.
Die einzige regelmäßigkeit die mir auffällt ist, dass der Absender-Server sich bis zu fünf mal erfolgreich mit unserer Firewall verbindet, dann aber gleich der Server der Telekom drei mal mit dem selben SRC PORT verbinden versucht (2 mal davon gelingt es, beim dritten mal bekommt er ein "deny" mit Fehlernachricht "no session matched") und die Mail im Fallback landet......
Gibt es da eine Einstellmöglichkeit diesbezüglich in der Fortigate?!
Heute kommt der Telekom-Techniker um das Modem zu tauschen und die Leitungen durchzumessen... Mal schauen was dabei raus kommt...
Konfiguration: schlechtes Österreichisches Telekom ADSL Internet (sind im äußersten Einzugsgebiet), Fortigate 50B v4.0,build0511,120110 (MR3 Patch 4), SBS 2003 mit MX3 Eintrag auf unseren Server und Backup-Mail-Server bei der Telekom falls wir mal einen Stromausfall haben (relativ häufig bei uns - jedoch hängt die gesamte Hardware an USVs.
Ich freue mich schon auf Eure Hilfe, deshalb schon ein herzliches Vielen Dank im Voraus!
Gruß
Florian
NACHTRAG:
Manchmal funktioniert die Verbindung vom Telekom-Server jedoch und es werden ein paar Mails die darin liegen zugestellt... War zumindest letzte Woche noch so...
2. Nachtrag:
So sieht das ganze im Traffic Log bei der Fortigate aus:
Der 213.33.87.8 ist der MX3.bon.at (Backup-Server der Telekom)
Der 195.70.115.204 ist der SMTP von unserem Kunden... >> Es kommt aber keine Mail durch...
3. Nachtrag:
Telekom Austria Techniker war gerade da und hat den Router und im Wählamt die Gegenstelle getauscht - kein Unterschied...
4. Nachtrag:
Wir haben gestern die Fortigate zurückgesetzt und die MR2 Patch10 aufgespielt... Neu konfiguriert und seither funktionierts... Mal schaun was der Analyzer noch so loggt....
Wir haben seit 13.01. ein Problem mit der Zustellbarkeit der Mails die an uns gesendet werden.
Die Mails werden an uns gesendet, die Fortigate hat im Traffic-Log den Verbindungsversuch drinnen und schreibt nach zwei erfolgreichen Verbindungen eine "deny" Meldung rein und als Fehlernachricht steht "no session matched".
Das lustige daran: Das passiert nicht bei allen Mails - aber auch nicht nur bei bestimmten. Wir haben Kunden / Lieferanten von Deutschland, Slowenien und Österreich wo wir dieses Problem haben...
Nochmals Mahlzeit.
Nun ein bisschen ausführlicher:
Aufgefallen ist die Thematik am 17.01. weil mein Chef meinte er warte auf ein E-Mail von einem Kunden das bis jetzt noch nicht angekommen ist. Eine Kollegin meinte dann "ja, ich warte auch auf ein Mail" daraufhin bin ich stutzig geworden und habe die Logs der Firewall durchsucht - aber nichts gefunden. Dachte zuerst natürlich an den Spam-Filter und habe die betreffenden Mail-Adressen auf die Whitelist gesetzt - hat aber nichts gebracht. Dann habe ich noch die SMTP Server vom Absender auf die Whitelist gesetzt - hat auch nichts gebracht, die IP Adresse des Telekom Servers auf die Whitelist > kein Erfolg. Das komplette UTM Profil neu angelegt - keine manuellen Spam-Filter hinterlegt, jeglichen Internetverkehr "verboten" (Internetradios,... wohlgemerkt nicht in der Firwall verboten, sondern per interner Mail an die Leute geschickt) Firewall neu gestartet, Firmware aktualisiert, unzählige Stunden mit der Telekom-Hotline verbracht (bzgl. der Unzustellbarkeit der Nachrichten die bei denen im Fallback liegen). Jetzt hatte ich gestern nochmal einen Techniker von unserem EDV-Systemhaus hier und der meinte auch nur "Firewall ist richtig konfiguriert, passt soweit alles. Einziges der Upload von 0,3mbit ist schlecht". Heute hatte ich einen Upload von 0,1 - 0,2 mbit. (gemessen mit speedtest.net und speedmeter.de auf dem Salzburger Server).
Am Exchange kann es nicht liegen, da ich die Mail gar nicht mal bei der Fortigate durch bekomme.
Die einzige regelmäßigkeit die mir auffällt ist, dass der Absender-Server sich bis zu fünf mal erfolgreich mit unserer Firewall verbindet, dann aber gleich der Server der Telekom drei mal mit dem selben SRC PORT verbinden versucht (2 mal davon gelingt es, beim dritten mal bekommt er ein "deny" mit Fehlernachricht "no session matched") und die Mail im Fallback landet......
Gibt es da eine Einstellmöglichkeit diesbezüglich in der Fortigate?!
Heute kommt der Telekom-Techniker um das Modem zu tauschen und die Leitungen durchzumessen... Mal schauen was dabei raus kommt...
Konfiguration: schlechtes Österreichisches Telekom ADSL Internet (sind im äußersten Einzugsgebiet), Fortigate 50B v4.0,build0511,120110 (MR3 Patch 4), SBS 2003 mit MX3 Eintrag auf unseren Server und Backup-Mail-Server bei der Telekom falls wir mal einen Stromausfall haben (relativ häufig bei uns - jedoch hängt die gesamte Hardware an USVs.
Ich freue mich schon auf Eure Hilfe, deshalb schon ein herzliches Vielen Dank im Voraus!
Gruß
Florian
NACHTRAG:
Manchmal funktioniert die Verbindung vom Telekom-Server jedoch und es werden ein paar Mails die darin liegen zugestellt... War zumindest letzte Woche noch so...
2. Nachtrag:
So sieht das ganze im Traffic Log bei der Fortigate aus:
Der 213.33.87.8 ist der MX3.bon.at (Backup-Server der Telekom)
Der 195.70.115.204 ist der SMTP von unserem Kunden... >> Es kommt aber keine Mail durch...
3. Nachtrag:
Telekom Austria Techniker war gerade da und hat den Router und im Wählamt die Gegenstelle getauscht - kein Unterschied...
4. Nachtrag:
Wir haben gestern die Fortigate zurückgesetzt und die MR2 Patch10 aufgespielt... Neu konfiguriert und seither funktionierts... Mal schaun was der Analyzer noch so loggt....
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 179813
Url: https://administrator.de/forum/fortigate-50b-laesst-keine-verbindung-vom-telekom-fallback-server-zu-179813.html
Ausgedruckt am: 22.12.2024 um 17:12 Uhr
6 Kommentare
Neuester Kommentar
Hallo.
Nimm den raus, ist nicht nötig. Jeder ordentlicher Mailserver versucht bis zu 48 Stunden lang Mails zuzustellen. Erst dann wird ein NDR an den Absender genriert.
Ein 2. MX ist eher hinderlich, da dieser auch gegen SPAM abgesichert werden muss.
LG Günther
und Backup-Mail-Server bei der Telekom falls wir mal einen Stromausfall haben
Nimm den raus, ist nicht nötig. Jeder ordentlicher Mailserver versucht bis zu 48 Stunden lang Mails zuzustellen. Erst dann wird ein NDR an den Absender genriert.
Ein 2. MX ist eher hinderlich, da dieser auch gegen SPAM abgesichert werden muss.
LG Günther
Hallo,
bei der Firmware-Aktualisierung bist du meiner Meinung nach zu Weit gegangen: FortiOS 4.0 MR3 ist für den Produktivbetrieb noch nicht ausreichend stabil, du solltest besser FortiOS 4.0 MR2patch10 verwenden. (ein Downgrade der Firmware wird jetzt allerdings schwierig).
Ansonsten nehme ich an, das du den Mailempfang (SMTP) über eine virtuelle IP konfiguriert hast?
Das sollte eigentlich problemlos funktionieren, wir haben hier eine ähnliche Konfiguration.
mfg
Harald
bei der Firmware-Aktualisierung bist du meiner Meinung nach zu Weit gegangen: FortiOS 4.0 MR3 ist für den Produktivbetrieb noch nicht ausreichend stabil, du solltest besser FortiOS 4.0 MR2patch10 verwenden. (ein Downgrade der Firmware wird jetzt allerdings schwierig).
Ansonsten nehme ich an, das du den Mailempfang (SMTP) über eine virtuelle IP konfiguriert hast?
Das sollte eigentlich problemlos funktionieren, wir haben hier eine ähnliche Konfiguration.
mfg
Harald
Hallo Flobert,
ich nehme an, der Screeshot stammt aus dem Traffic Log? Kannst du bitte den kompletten "Deny"-Eintrag hier posten? (am Besten im RAW-Modus als Text).
Habt ihr evtl. eine DoS-Policy?
Alternativ kannst du ja auch versuchen den Traffic zu sniffen (am Besten mit Putty, da kannst du alles in ein Log schreiben lassen und dieses dann später in Ruhe auswerten)
diag sniff packet any 'tcp and port 25 an host 213.33.87.8' 3
mfg
Harald
ich nehme an, der Screeshot stammt aus dem Traffic Log? Kannst du bitte den kompletten "Deny"-Eintrag hier posten? (am Besten im RAW-Modus als Text).
Habt ihr evtl. eine DoS-Policy?
Alternativ kannst du ja auch versuchen den Traffic zu sniffen (am Besten mit Putty, da kannst du alles in ein Log schreiben lassen und dieses dann später in Ruhe auswerten)
diag sniff packet any 'tcp and port 25 an host 213.33.87.8' 3
mfg
Harald