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

VLAN Trunking mit RED50

Hallo zusammen,

Vielleicht kann mir hier ja jemand einen cleveren Tipp oder Denkanstoß geben. Ich sehe mittlerweile nur noch Fragezeichen.

wir haben eine SG230 in unserem Hauptsitz in Betrieb. Hier gibt es einen Haufen VLANs; das interessante ist unser Voice VLAN mit der ID 140. Um meine Telefone in einem Standort, der mit einem RED50 angeschlossen ist, betreiben zu können, habe ich versucht, dieses VLAN über das RED zu trunken. Ich habe mich hierbei an diese Anleitung gehalten: https://support.sophos.com/support/s/article/KB-000038272?language=en_US

Das Testlabor ist ganz simpel: Ein Cisco SG300 Switch auf dem zu Testzwecken erstmal nur das VLAN 8 eingerichtet ist. Das standardmäßige 1er VLAN habe ich dahin ausgetauscht, da dieses ja scheinbar bei Sophos für Web Protection genutzt wird(Edit: Wireless Protection - Kommunikation mit Access Points). Um Fehler zu umschiffen gibt es also erstmal nur VLAN 8. Der Switch hat die IP 192.168.8.236. Den Switch habe ich beim ersten Versuch als Layer 2 mit Standardgateway eingerichtet, beim zweiten Versuch als Layer 3 mit der Route 0.0.0.0/0 zu 192.168.8.254. Die .254 ist die Schnittstelle meines RED50. Wenn ich mein RED50 auf Switch Modus stehen lasse, erreiche ich mein RED und das Szenario funktioniert. Stelle ich nun auf VLAN um, fangen die Probleme an. Ab dem Moment erreiche ich vom Netz am Switch das RED nicht mehr.

Ich habe schon das RED und den Trunk an meinem Switch auf getaggte Pakete und ungetaggte Pakete konfiguriert, andere VLANs erstellt um es mit denen zu versuchen, aber ich bin niemals in der Lage, mein RED zu erreichen. Die VLAN ID 8 habe ich natürlich korrekt eingetragen. Die VLANs habe ich auf der UTM auch auf der Ethernet Bridge eingerichtet. Ob die Pakete getagged bei der UTM ankommen ist mir auch erstmal zweitrangig. Wenn ich mein RED im VLAN Modus pingen kann, wäre ich schon mal sehr zufrieden.

Hat jemand so ein Szenario schon mal aufgebaut und kann mir vielleicht helfen? Oder mir sagen, wie ich noch helfen kann mir zu helfen? Die config von meinem Switch ist ja eigentlich uninteressant, da außer der statischen IP, der einzelnen Route und dem einzelnen VLAN und, Access und Trunk Port nichts konfiguriert ist und alles geht, bis ich das RED auf VLAN umschalte. Beim RED widerum auf VLAN zu klicken und LAN Port 1 die VLAN ID 8 untagged oder tagged zuzuweisen lässt auch wenig Raum für Fehler. Ich bin ratlos... 



This thread was automatically locked due to age.
  • Moin Pete

    Nur ein Überlegungsansatz:

    Alle Pakete, die über die konfigurierte Bridge (Interface mit RED-Interface gebrückt) gehen, passieren den Firewall-Stack. Das heißt, es muss immer auch eine Regel geben, die das gebrückte Netz auf sich selber zulässt. z.B. 192.168.8.0/24 <-> any <-> 192.168.8.0/24. Hast Du das auch für die Netze gemacht, die in den VLANs kommunizieren?
    Hast Du Objekte an Interfaces gebunden - oder so wie in Bob's Rulz empfohlen ohne Bindung erstellt?

    LG, Janbo

    ---

    janbo.noerskau@comedia.de UTM lover ;-)

  • Hallo Janbo!

    Danke für deinen Input. Ich habe mal nicht nur deine Regel erstellt, sondern auch zum Test any any 192.168.8.0/24 und 192.168.8.0/24 any any angelegt - leider keine Veränderung. Das hätte mich auch gewundert, denn vom Netz hinter der UTM (also meiner normalen Workstation) kann ich das RED jederzeit erfolgreich pingen. Also vom UTM Netz zur RED scheint alles propper, nur wenn ich ihn auf VLAN Modus stelle, LAN1 auf untagged VLAN ID 8 und mit meinem Switch mit einem untagged VLAN ID 8 Trunk Port verbinde, geht leider nücht durch. Wie schon erwähnt gilt das auch für die gleiche Konstellation, aber mit tagged Ports. Aber danke für die Anregung!

    Im Bezug auf das Objekt am Interface: Jein. Wenn ich die Ethernet Bridge oder eine normale Schnittstelle für das RED erstelle, dann legt die UTM mir ja auch automatisch ein Netzwerk, Adressen und Broadcast Objekt an. Diese sind an die Schnittstelle gebunden. Die Objekte benutze ich dann auch. Ich werde dann also alle meine Objekte jetzt einmal händisch ohne Bindung neu erstellen und dann auf den Regeln und sonst wo ersetzen. Ich melde mich nochmal, wenn ich das ganze getestet habe!

    Edit: Wenig verwunderlich, aber das umändern vom gebundenen in das ungebundene Netzwerkobjekt hat leider auch nichts an der Situation verändert.

  • Hallo Pete,

    (Sorry, my German-speaking brain isn't creating thoughts at the moment. Frowning2)

    I think you've proven that the problem is in your smart switch, but, to confirm that, check the firewall log as suggested in #1 in .Rulz (last updated 2021-02-16).

    MfG - Bob (Bitte auf Deutsch weiterhin.)

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Moin

    Sorry, dass ich da nicht schon früher reagiert habe.

    Es geht tatsächlich nur um die Schnittstellenbindung, wenn man selbst Objekte erstellt. Bei UTM-internen Objekten (also z.B. Schnittstellen) ist die Bindung OK und die Objekte können auch prima genutzt werden.

    ---

    janbo.noerskau@comedia.de UTM lover ;-)

  • Hey Alfons,

    in welche Logs soll ich denn schauen und weißt du wonach ich Ausschau halte? WAN ist ok, vom UTM Netzwerk erreiche ich, wie erwähnt, das RED. Nur das VLAN Routing geht nicht am angeschlossenen LAN. Sowas hält die UTM in den Logs fest?

    Im RED Log sehe ich natürlich die ganzen PINGs und PONGs und kriege auch mit, wie mein RED bei meinen Änderungen eine neue config zieht. Weiter finde ich aber nichts Interessantes.

    2021:08:30-10:47:06 red_server[26715]: SELF: New connection from *.*.*.* with ID A340256A916XXXX (cipher AES256-GCM-SHA384), rev1
    2021:08:30-10:47:06 red_server[26715]: A340256A916XXXX: connected OK, pushing config
    2021:08:30-10:47:07 red_server[26715]: A340256A916XXXX: command '{"data":{"version":"0"},"type":"INIT_CONNECTION"}'
    2021:08:30-10:47:07 red_server[26715]: A340256A916XXXX: Initializing connection running protocol version 0
    2021:08:30-10:47:07 red_server[26715]: A340256A916XXXX: Sending json message {"data":{},"type":"WELCOME"}
    2021:08:30-10:47:09 red_server[26715]: A340256A916XXXX: command '{"data":{},"type":"CONFIG_REQ"}'
    2021:08:30-10:47:09 red_server[26715]: A340256A916XXXX: Sending json message {"data":{"pin":"","fullbr_dns":"","split_networks":"1.2.3.4","lan2_vids":"8","lan4_vids":"","local_networks":"","tunnel_id":8,"manual2_netmask":24,"asg_cert":"[removed]","manual_address":"0.0.0.0","bridge_proto":"none","unlock_code":"pz99XXXX","password":"","manual2_defgw":"0.0.0.0","prev_unlock_code":"pz99XXXX","manual_netmask":24,"lan3_vids":"","mac_filter_type":"none","mac":"00:4e:ed:69:XX:XX","dial_string":"*99#","manual2_address":"0.0.0.0","version_ng_red50":"1-470-0a7bdb107-0000000","manual_dns":"0.0.0.0","poe_port1":0,"poe_port2":0,"lan1_mode":"untagged","username":"","activate_modem":0,"tunnel_compression_algorithm":"lzo","version_red50":"1-470-0a7bdb107-0000000","fullbr_domains":"","htp_server":"platzhalter.domain.de","uplink_balancing":"failover","asg_key":"[removed]","type":"red50","deployment_mode":"online","uplink2_mode":"dhcp","manual2_dns":"0.0.0.0","lan2_mode":"...L1445
    2021:08:30-10:47:13 red_server[26715]: A340256A916XXXX: command '{"data":{"key1":"YwQsX87EFN+5YN0TavUI8UleZ0PSsviAMbStrr+E8N4=","key0":"A9uyPPoitFTIw+c1Cse\/buC5jXQbfRAwy\/u1vEH+HkQ=","key_active":0},"type":"SET_KEY_REQ"}'
    2021:08:30-10:47:13 red_server[26715]: A340256A916XXXX: Sending json message {"data":{},"type":"SET_KEY_REP"}
    2021:08:30-10:47:14 red_server[26715]: A340256A916XXXX: command '{"data":{"seq":0},"type":"PING"}'
    2021:08:30-10:47:14 red_server[26715]: id="4201" severity="info" sys="System" sub="RED" name="RED Tunnel Up" red_id="A340256A916XXXX" forced="0"
    2021:08:30-10:47:14 red_server[26715]: A340256A916XXXX: Sending json message {"data":{"seq":0},"type":"PONG"}
    2021:08:30-10:47:14 red2ctl[4647]: Overflow happened on reds8:0
    2021:08:30-10:47:14 red2ctl[4647]: Missing keepalive from reds8:0, disabling peer *.*.*.*
    2021:08:30-10:47:15 red_server[26715]: A340256A916XXXX: command '{"data":{"wan1_ip":"192.168.9.104","uplink":"WAN1","uplink_state":"0"},"type":"STATUS"}'
    2021:08:30-10:47:16 mail01 red_server[4631]: SELF: (Re-)loading device configurations
    2021:08:30-10:47:30 mail01 red_server[26715]: A340256A916XXXX: command '{"data":{"seq":1},"type":"PING"}'
    2021:08:30-10:47:30 mail01 red_server[26715]: A340256A916XXXX: Sending json message {"data":{"seq":1},"type":"PONG"}

    E: Danke schon mal für eure Zeit bis hierhin. Ich versuche mich die Woche nochmal mit den Bildern und Logs zurückzumelden, aber hier ists momentan etwas stressig.

  • I meant the packetfilter (firewall) log - are there any related blocks there?

    Let's also check Janbo's suggestion - show pictures of the Edit of the RED Server definition with 'Advanced' and 'Switch port configuration' open.  Also the Edits of any related firewall rules.

    MfG - Bob (Bitte auf Deutsch weiterhin.)

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Lange ist es her, aber ich hatte wieder die Möglichkeit, mich mit dem Thema auseinanderzusetzen. Diesmal habe ich mir Unterstützung mitgebracht, aber auch wieder fast alles vergessen, was ich beim letzten Mal getan hatte. Diesmal hat aber alles funktioniert. Es war nicht die Firewall und auch nicht die RED Konfiguration. Der Wurm muss irgendwo beim Switch gewesen sein, wo die Kombination aus Interface und statischer Route nicht richtig funktioniert hat. Ich hab keine config vom Switch um zu vergleichen, was genau da falsch war, aber ich kann mich zumindest drüber freuen, dass alles funktioniert.

    Danke für eure Hilfe!

  • Lange ist es her, aber ich hatte wieder die Möglichkeit, mich mit dem Thema auseinanderzusetzen. Diesmal habe ich mir Unterstützung mitgebracht, aber auch wieder fast alles vergessen, was ich beim letzten Mal getan hatte. Diesmal hat aber alles funktioniert. Es war nicht die Firewall und auch nicht die RED Konfiguration. Der Wurm muss irgendwo beim Switch gewesen sein, wo die Kombination aus Interface und statischer Route nicht richtig funktioniert hat. Ich hab keine config vom Switch um zu vergleichen, was genau da falsch war, aber ich kann mich zumindest drüber freuen, dass alles funktioniert.

    Danke für eure Hilfe!