Sophos red 15 in Betrieb nehmen

Hallo Kollegen,
ich möchte eine RED-15 in Betrieb nehmen. Diese soll an einen Speedport W723V Typ B angeschlossen werden. Der Provider ist Deutsche Telekom AG.  Der Speedport hat wanseitig ne feste IP. (Business Anschluss)

Soweit so gut. Eine Verbindung zur sophos UTM9 kann leider nicht aufgebaut werden.
Wenn ich mir die LEDs des Gerätes anschaue  (Error States) sieht das bei mir kurz vor dem Neustart so aus, dass die Power LED an ist, die System LED rot blinkt, die Router LED an  ist und Internet blinkt, Tunnel ist komplett aus.  Also das, was unter https://community.sophos.com/kb/en-us/116173 neben  (Gateway is reachable, but mobile broadband connection failed. No connection to ASG/UTM or provisioning service.) steht.

Die Red ist am Speedport sichtbar, ich sehe die Macadresse und sehe auch, dass hier eine IP zugewiesen wurde.  Ich kann diese IP auch anpingen. Beim Neustart der Red geht der ping natürlich weg.
Am Speedport sind port 3000 bis 3500 TCP und UDP für das Gerät per Nat-Firewall freigegeben.

Was kann ich tun, damit die Red sich verbindet?
Ich habe es auch an einem anderen Standort ausprobiert mit dem gleichen Ergebnis.



  • In reply to kerobra:

    kerobra

    Was Du am Speedport an NAT eingerichtet hast ist INBOUND, interessiert die RED herzlich wenig, die muss OUTBOUND über diese Ports kommunizieren können.

    Outbound ist meiner Meinung nach standardmäßig nichts blockiert. Ich kann da auch nichts Freischalten.

     

    kerobra

    Wenn an der UTM keine RED-Verbindung ankommt kann entweder die Config für die RED dort falsch sein (die Provisionierung läuft auf falsche Adressen)


    Wie überprüfe ich das? Wenn ich die Quick-Anleitung von Sophos lese ist das so erklärt, als ob jeder Baumschüler die RED in Betrieb nehmen kann.

    kerobra

    , die UTM steht nicht direkt im Internet...

    Das tut sie mit einer statischen Öffentlichen IP. Es kommen auch Mails ohne Probleme über die UTM rein.

    kerobra

    ..und die für die RED-Verbindung benötigten Ports kommen nicht bei ihr durch...


    Kann man das irgendwie prüfen?

     

    kerobra

    ...oder die RED kommt erst gar nicht über den Speedport hinaus.

    Dann würde sie bei zwei verschiedenen speedport Modellen mit  zwei verschiedenen Telekom Business Anschlüssen nicht ins Internet kommen.  Wenn man jetzt wüsste, ob die Internet-LED auch bedeutet, dass wirklich eine Verbindung zum Internet besteht, könnte man das bestätigen. Leider habe ich hier eine Blackbox bzw. whitebox wo ich außer die LEDs nicht sehe. Wofür der Konsolenanschluss vorhanden ist, weiß ja kein Mensch.
    Ich kann sie am Montag jedoch auch an einen anderen Anschluss mit Zyxel-Router hängen, dann wissen wir mehr.

     

     

     

     
  • In reply to Klaus Kinsky:

    Ich danke allen Beteiligten und wünsche euch schon mal ein schönes Wochenende.

  • In reply to kerobra:

    kerobra

    Vermutlich wirst Du die Antwort bekommen, dich an Deinen Reseller zu wenden.

    So ist es, 1A Support! Da bin von anderen Firewall-Herstellern was Anderes gewöhnt!

  • Hallo,

     

    Existiert ein tcpdump von der UTM?

    tcpdump -ni any host IP_WAN_RED

     

    Baut die RED die Verbindung auf - Kommen die Pakete an der UTM an?

    Es müssen Port 3400 und Port 3410 Pakete zu sehen sein.

     

    Bitte folgende Screenshots:

    LAN Interface

    RED Interface

     

    Nächste Punkt überprüfen:

    utm:/root # cc get red tls_1_2_only

    Ist der Output 1 oder 0?

     

    Gruß

  • In reply to ManBearPig:

    Hallo und vielen Dank für die Hilfe

    ManBearPig

    Existiert ein tcpdump von der UTM?

    tcpdump -ni any host IP_WAN_RED

    erstelle ich noch, aber ich denke da wird nichts enthalten sein.

    ManBearPig

    Baut die RED die Verbindung auf - Kommen die Pakete an der UTM an?

    Nein, es kommt nichts an. Im Dashboard war und ist der Link auf aus.
    Bei der RED geht ja auch wie gesagt nicht die Internet LED an.

    Es müssen Port 3400 und Port 3410 Pakete zu sehen sein.

    Die Ports sind aufjedenfall nicht vom ISP Blockiert.

    Ein Nmap scan von einem Laptop am remote-standort, der direkt an den router angeschlossen ist, sagt mir folgendes


    Starting Nmap 7.12 ( https://nmap.org ) at 2017-08-15 16:09 Mitteleuropõische Sommerzeit
    Nmap scan report for red.astaro.com (46.51.176.142)
    Host is up (0.66s latency).
    rDNS record for 46.51.176.142: ec2-46-51-176-142.eu-west-1.compute.amazonaws.com
    PORT     STATE SERVICE
    3400/tcp open  csms2

    Nmap done: 1 IP address (1 host up) scanned in 2.66 seconds

    c:\Program Files (x86)\Nmap>nmap red.astaro.com -p3410

    Starting Nmap 7.12 ( https://nmap.org ) at 2017-08-15 16:09 Mitteleuropõische Sommerzeit
    Nmap scan report for red.astaro.com (46.51.176.142)
    Host is up (1.3s latency).
    rDNS record for 46.51.176.142: ec2-46-51-176-142.eu-west-1.compute.amazonaws.com
    PORT     STATE SERVICE
    3410/tcp open  networklenss

    Also gehe ich davon aus, dass auch die Red, die ja am gleichen router hängt rauskommen kann, sofern

    sie denn möchte.

     


    Bitte folgende Screenshots:
    LAN Interface
    RED Interface

     Eingehende und ausgehende Pakete waren in der Red-schnitstelle immer auf 0. Screenshot sind beigefügt.

    Nächste Punkt überprüfen:

    utm:/root # cc get red tls_1_2_only

    Ist der Output 1 oder 0?

     

    kommt noch

  • In reply to Klaus Kinsky:

     

    Hier noch ein screenshot von der Schnittstelle mit IP. 44.100

     

    Der DHCP bereich im router  am remote standort steht von 44.20 bis 44.40

     

    Die Mac adresse, die im Router zu sehen ist, ist die von der WAN-Schnitstelle.

    Ich kann die IPvom Laptop aus anpingen. Der Ping schlägt im dem moment fehl, wo die Sophos neustartet.

     

     

  • In reply to Klaus Kinsky:

    Der TCP Dump ist leider leer.

    vgk-Astaro9:/root # tcpdump -ni any host 192.168.44.100

    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

    listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes

    0 packets captured

    0 packets received by filter

    0 packets dropped by kernel

    <M> vgk-Astaro9:/root #

    Wenn ich einen TCP-dump von der Lan Schnittstelle mache, laufen die Pakete nur so durch.

  • In reply to Klaus Kinsky:

    Hallo,

     

    denke der Fehler ist die Interface Konfig.

    RED WAN: 192.168.44.X DHCP

    Und RED LAN soll auch 192.168.44.X bekommen?

     

    Daher kommt die RED nicht online. Ist ein Routing Problem, da die Appliance zwei Interface mit selben Subnetz hat.

    Bitte den WAN Bereich einmal ändern auf 192.168.45.X/24 oder 192.168.1.X/24 von dem Speedport.

     

     

    Screenshot bitte von LAN Interface Konfig und REDs Konfig.

    Im Dump bitte die WAN IP von der RED angeben. 

     

    Gruß

  • In reply to ManBearPig:

    Hallo, ja alles was am remote Standort ist und die Red-(WAN) Schnittstelle der Sophos-UTM sollen im Bereich 192.168.44.x /24 liegen. So hätte ich es jetzt aufgebaut. Ich habe nirgendswo gelesen, dass die RED (WAN)Schnittstelle der SOPHOS-UTM in einem anderen Subnetz liegen muss. Wenn es da infos oder Links gibt, immer her damit.

    Der 192.168.1.x Bereich möchte ich nicht benutzten, da der unter Umständen von VPN-Benutzern verwendet wird, die nicht die Red nutzen und ich nicht weiß, ob dies zu Problemen führen könnte.

    Daher habe ich am Router des remote Standortes jetzt auf 43.x umgestellt.  Der router hat 192.168.43.254, die RED  (WAN) 43.21  und das Laptop, welches am router hängt 43.20. Natürlich mit /24 als Subnetzmaske. Alles wird per DHCP vergeben. Das Ergebnis ändert jedoch nichts.

    Die Red1 Schnitstelle an der Sophos UTM hat nach wie vor die 192.168.44.100/24. Da kommt im TCP-Dump nichts an.  Auf 192.168.43.21 kommt auch nichts an.  Was macht

    utm:/root # cc get red tls_1_2_only
    Ich bin immer sehr vorsichtig was Befehle angeht, die ich nicht kenne und die als root ausgeführt werden.

  • In reply to Klaus Kinsky:

    Hier noch ein Bild der Red config.

  • In reply to Klaus Kinsky:

    Hallo,

     

    der CC Befehl holt nur die Konfig einstellung aus dem CC. Keine Changes werden damit ausgeführt.

     

    Es fehlt noch der Dump vom TCPdump mit der WAN IP der RED.

    Was steht in der UTM-Hostname drin? Wurde hier die IP von der UTM getestet?

     

    Gruß

  • In reply to ManBearPig:

    Hallo und danke für die Hilfe.

    ManBearPig

    Hallo,

    Es fehlt noch der Dump vom TCPdump mit der WAN IP der RED.

    Das wäre ja dann die 192.168.43.21, welche per DHCP vom speedport zugewiesen wurde.

    <M> vgk-Astaro9:/root # tcpdump -ni any host 192.168.43.21

    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

    listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes



    Da kommt nix an, auch nach 5 Minuten nicht

    Im Dashboard der UTM ist der Link auch nach wie vor auf aus.

    Was steht in der UTM-Hostname drin? Wurde hier die IP von der UTM getestet?

    Nein, nur ein Name des remotestandortes.

     
    Das war die Lösung gewesen, die Lampen sind jetzt an, nachem die IP dort steht.
    Auch der link in der UTM9 ist da.
    Super, danke
  • In reply to Klaus Kinsky:

    Klaus Kinsky
    Das war die Lösung gewesen, die Lampen sind jetzt an, nachem die IP dort steht.
    Auch der link in der UTM9 ist da.
    Super, danke

     
    Eieiei genau das hat mir auch geholfen :/ so ein Mist... wir haben unseren ISP geändert und somit die IP-Adresse der UTM im Hauptstandort, allerdings haben wir das wacker im DNS nachgetragen. Ich hatte eigentlich gehofft das passt.
    Interessanterweise muss das irgendeine negotiation-Sache sein, da ich genau die weiter oben bereits erwähnte Meldung im Log gefunden habe: »Self: SSL accept attempt failed with unknown error error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol«
     
    Die IP-Adresse haben wir ja auch nur in der UTM geändert ohne dass Verbindung zur RED bestand, die RED connected scheinbar weiterhin via DNS Hostname…
    was weiß ich, "hauptsache es geht wieder". Blöd allerdings.
     
    Beste Grüße!!