Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 1 subscriber
  • Views 7454 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SMTP Port wird nicht nach außen durchgelassen

itpsc
Hallo Zusammen, ich habe folgende Rahmenparameter:
Sophos UTM 9.3-15
- 2 WAN Schnittstellen mit Upload-Ausgleich (100 und 0) damit die PCs zuerst mit der schnellen 100 MBit Leitung arbeiten und bei Ausfall die andere Leitung nehmen.
Die andere WAN Schnittstelle (2MBit) hat 5 zusätzliche öffentliche IP Adressen.

Ein Exchange Server 2013 steht im internen Netz und ein Exchange EDGE steht in der DMZ. Der Edge sendet und empfängt die E-Mails von/nach dem Internet und tauscht sie nach innen mit dem Exchange Server aus.

Versand muss über eine der zusätzlichen öffentlichen IPs der 2 MBit Leitung erfolgen.

1) Es gibt eine Multipath Regel um den Upload-Ausgleich zu umgehen:
    Bindung nach Schnittstelle
    EDGE Server - SMTP Messaging - Internet IPv4 - WAN_2MBit

2) Es gibt eine SNAT Regel für den ausgehenden SMTP Traffic:
     EDGE Server - SMTP Messaging - Internet IPv4 
     Quellübersetzung:  WAN_2MBit_IP139 (Adress)
     und eine dazu passende Firewallregel

3) Es gibt für den eingehenden SMTP Traffic eine DNAT Regel:
    Any - SMTP Messaging - WAN_2Mbit_IP139 (Adress)
    Zielübersetzung:   EDGE Server
    auch hier mit passender Firewall Regel

Effekt ist nun, dass man E-Mails an den EDGE Server schicken kann, aber
der EDGE Server keine E-Mail verschicken kann.
Ein Telnet vom EDGE Server nach außen zu einem anderen Mail Server auf
Port 25 kommt definitiv nicht durch.
Irgendwo muss wohl bei den Regeln in der Sophos ein kleiner Denkfehler liegen, da auf einer virtuellen TEST Sophos mit auch zwei WAN Leitungen und eigentlich den gleichen Regeln von dem virtuellen SBS2011 ein Telnet ins Internet auf Port 25 zu einem anderen Mail Server funktioniert.
Falls jemand eine Idee hätte wo denn der Denkfehler sein könnte würde mir das sehr weiterhelfen.
Noch erwähnen wollte ich, dass momentan der derzeitige IST Stand beim Wechsel auf die Sophos erhalten bleibt und dann in einem weiteren Schritt der EDGE Server von der Sophos als E-Mail Proxy abgelöst wird.

Und am Rande eine Frage in die Runde: gibt es für die Sophos denn eventuell auch eine "angenehmere" Art der Darstellung innerhalb der Logfiles? Die TMG2010 hat zwar nur eine einzige Logfunktion aber die zeigt einem sofort und so gesehen sehr übersichtlich die Datenpakete mit den Infos:  Quell IP - Ziel IP - Port - matching rule - allow/deny.......

Über einen guten Tipp wo mein Denkfehler im Regelwerk steckt
würde ich mich freuen, damit die Sophos auch demnächst die
TMG2010 dauerhaft ersetzen kann.

B. Giggenbach


This thread was automatically locked due to age.
  • 0
    Irgendwas im Firewall- oder IPS-Log zu sehen?
    Mail Protection auf der UTM aktiv?

    ----------
    Sophos user, admin and reseller.
    Private Setup:

    • XG: HPE DL20 Gen9 (Core i3-7300, 8GB RAM, 120GB SSD) | XG 18.0 (Home License) with: Web Protection, Site-to-Site-VPN (IPSec, RED-Tunnel), Remote Access (SSL, HTML5)
    • UTM: 2 vCPUs, 2GB RAM, 50GB vHDD, 2 vNICs on vServer (KVM) | UTM 9.7 (Home License) with: Email Protection, Webserver Protection, RED-Tunnel (server)
  • 0
    Mail Protection ist alles komplett aus..... weil das erst später ein Thema wird.....

    ......man kann anscheinend doch auch etwas in den Logs suchen........ da sind dann schon Treffer drin die mit DROP bezeichnet sind...... aber der Rest ist erstmal noch nicht wirklich weiterführend für mich........

    /var/log/packetfilter.log:2015:09:22-00:16:03 ***x_gw1 ulogd[5084]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth1" outitf="eth6" srcmac="00:b0:c2:88[:D]b:00" dstmac="00:1a:8c:58:91[:D]5" srcip="aaa.bbb.ccc.ddd" dstip="192.168.1.14" proto="6" length="48" tos="0x00" prec="0x00" ttl="123" srcport="41560" dstport="25" tcpflags="SYN"

    Da ist der HostName der Sophos ....Ziel IP ...... interne Quell IP.... Port  ... ttl.......
    ....aber kann man daraus auch schließen was und warum das Paket einen DROP bekommen hat?

    Zum Beispiel steht da fwrule="60002"   .....würde ich als Firewallrule sehen.....
    aber ist 60002 ein Fehlercode oder ist das die Nummer einer meiner Regeln?
  • 0
    Das ist die letzte Regel in der Kette und die ist auf einer UTM immer DROP. Folglich gab es vorher keine passende Regel.
    Allerdings sieht das nach einer eingehenden Verbindung aus. Was ist diese 192.168.1.14?

    Was ist unter "passender Firewall Regel" zu verstehen? Bei dem SNAT testweise die Autom. PFL gesetzt?
  • 0
    ...... 192.168.1.14 ist der Exchange EDGE Server in der DMZ, der die E-Mails ins Internet verschicken soll und von dem aus ich mit Telnet eine Verbindung auf Port 25 versucht habe.....

    Mit den sehr guten Hinweisen, dass Name="Packet dropped" dann wohl die letzte Regel in der Kette ist (TMG2010 -> Default Rule ..... jeder darf erstmal gar nichts...) steht also fest dass es keine "passende Regel" gibt, die beim Durchlauf durch das Regelwerk sich "angesprochen" fühlt das Datenpaket zu behandeln. Eine Regel muss "passen" um sich um das Datenpaket zu "kümmern" und dann im nächsten Schritt noch zu entscheiden ob es von dieser Regel durchgelassen wird oder ob es von dieser Regel blockiert wird.

    Aufgrund der wirren Darstellung der Logfiles ist mir gar nicht aufgefallen und deshalb danke für den nächsten Hinweis, dass es hier tatsächlich bei QuellIP  um die externe IP und bei ZielIP um den EDGE Server handelt, was dann ja bedeutet, dass nicht das von Telnet ausgehende Datenpaket gesperrt wurde, sondern die Antwort vom externen Mailserver auf Port 25.......weil zu diesem Zeitpunkt habe ich mit der externen IP und dem dahinter stehenden Mailserver definitiv von intern aus versucht eine Telnet Port 25 Verbindung aufzubauen........ 

    Das ist jetzt ein definitiver Ansatzpunkt für die weitere Suche warum der EDGE auf Port 25 nicht komplett kommunizieren kann.
  • 0
    Ein Option wäre auch, mit tcpdump zu prüfen, ob und wo die Pakete rausgehen.
  • 0
    ...oder als andere Fragestellung .... könnte es sein dass sich eine eingehende DNAT Regel und eine ausgehende SNAT Regel gegenseitig in die Quere kommen?

    .....weil vom Internet aus kann man eine Telnetverbindung mit Port 25 zu unserem Exchange 
    EDGE Server aufbauen, was dafür spricht dass eigentlich die Datenpakete ja von extern zu
    EDGE Server durchgelassen werden...... Was die Sache ein wenig seltsam erscheinen lässt...... 

    .....beim Schreiben kommen dann meistens weitere Ideen......Wenn das ausgehende Datenpaket von
    einer Regel durchgelassen wurde, wer oder was in einer Firewall kümmert sich dann darum
    wie die Antwort auf ein beantwortetes Datenpaket behandelt wird.....

    Was gäbe es noch für eine Möglichkeit - eventuell mit nur einer NAT Regel 
    die Datenpakete - wenn E-Mails aus dem Internet angeliefert werden an den 
    Exchange EDGE Server zu leiten und im Falle des E-Mail Versandes den Traffic von
    DMZ nach Extern über eine bestimmte WAN Schnittstelle und dort auch noch über
    eine der zusätzlichen öffentlichen IP Adressen zu verschicken?
  • 0

    3) Es gibt für den eingehenden SMTP Traffic eine DNAT Regel:
        Any - SMTP Messaging - WAN_2Mbit_IP139 (Adress)
        Zielübersetzung:   EDGE Server
        auch hier mit passender Firewall Regel


    Hallo B. Giggenbach,

    wenn ich es richtig deute hast du hier einen Konfigurationsfehler eingebaut. Any bedeutet alle Pakete die ankommen, auch die internen. Das bedeutet du hast einen Loop eingebaut. Trag mal anstatt any -> Internet IPv4 ein.

    vg
    mod
  • 0
    ....die neuesten Testergebnisse.

    1) Das mit ANY und Internet IPv4 in der DNAT Regel wurde als erstes geändert
        Neustart der Sophos Appliance.
        Test:   Telnet Verbindung vom EDGE auf externen E-Mail Server.......
                   Leider immer noch das gleiche Problem.

    2) Erstellung einer automatischen Firewall Regel bei der DNAT und der SNAT Regel
         aktiviert.
         Leider immer noch das gleiche Problem.

    3) Welche Unterschiede zu der virtuellen Test Sophos gibt es.......
        - Es gibt eine Maskierung von DMZ zu Uplink Interfaces
          -> Auch auf dieser Sophos eingerichtet, wenn auch vom
               Verständnis her dies nicht notwendig wäre....
         Leider immer noch das gleiche Problem.

       - Die Reihenfolge der beiden NAT Regeln (SNAT und DNAT), die sich auf den
         SMTP E-Mailverkehr von und zum EDGE Server beziehen, ist auf der Test Sophos
         genau umgekehrt. Die Reihenfolge geändert.
         Die Sophos Appliance noch einmal neu gestartet.
        
     -> Jetzt sind auch die zum Versand anstehenden E-Mails verschickt worden.
     TEST mit einer Telnet Verbindung zu dem externen E-Mail Server auf Port 25.
     - Beim ersten Versuch hat es einige Sekunden gedauert bis die Verbindung 
       aufgebaut war.
    - Verbindung getrennt.
    - Verbindung wieder aufbauen -> diesmal in weniger als eine Sekunde.

    Sophos Appliance noch einmal neu gestartet.
    - Wieder das gleiche Spiel bei Telnet 1. Versuch dauert mehrere Sekunden ab dem 2.Versuch kommt die Verbindung sofort zustande.

    Gefühlt wäre das Tauschen der NAT Regeln die Aktion gewesen, ab der Port 25 auch nach Außen durchgelassen wurde. Real würde es aber keinen Sinn ergeben. Die beiden NAT Regeln noch einmal in die alte Reihenfolge gebracht - Neustart der Sophos - 
    und es geht immer noch.

    Jetzt stellt sich die Frage warum...... und weshalb dauert der erste Telnet connect so lange?

    Ich bin fast an der Stelle, dass es eventuell besser wäre die Sophos Appliance zurück zu setzten und neu aufzubauen, weil eventuell in irgendwelchen INI und Konfi Dateien bei den vielen Versuchen und Änderungen noch Einträge verblieben sind, die dieses "interessante" Verhalten auslösen.......
  • 0
    Wahrscheinlich ein DNS Problem. Nicht zwingend auf der eigenen Seite.
  • 0
    ....wohl doch auf der eigenen Seite, weil wenn die TMG2010 tagsüber läuft, mit den gleichen DNS Servern, dann geht der Telnet connect gleich beim ersten Mal schnell....

    Aber egal....... wenn es erstmal funktioniert.....
Cookie Information Banner