Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 4 subscribers
  • Views 1623 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

WLAN hinter RED Performance

Andre Musso

Hallo Community,

 

ein Kunde hat in einem Branch Office, welches über eine RED50 (Standard/Split) an die Zentrale angebunden ist, einige Sophos WLAN-AP´s laufen. Im Normalfall funktionieren die auch einwandfrei. Jetzt gab es aber mehrfach den Fall dass in der Zentrale eine relativ hohe SSL-VPN-Last am Hauptgateway anlag, und in dieser Zeit funktioniert der WLAN-Internetzugang im genannten Branch-Office nicht mehr. Sobald die hohe SSL-VPN-Last in der Zentrale endet funktionieren die WLAN-Access-Points wieder.

Ich dachte da die Red50 im Branch Office auf Standard-Split konfiguriert ist wird auch der Internet-Traffic der WLAN-Accesspoints lokal rausgeführt und nicht über das Red-VPN zur Zentrale, was den "Performance-Hänger" erklären könnte...

Das WLAN-Netz ist gebridged ins AP-LAN, also in das LAN des Branch Offices.

 

Irgendwelche Ideen wie das WLAN auch bei hoher SSL-VPN-Last in der Zentrale noch funktioniert?

Andre



This thread was automatically locked due to age.
  • 0

    Hello Andre,

    Thank you for contacting the Sophos Community! 

    In standard/split, regular internet traffic shouldn't cross the RED and send out the regular internet gateway. 

    How do you configure the standard/split networks? And the Wireless network is a Separate Zone?

    Regards,

  • 0

    Hallo Andre,

    Ich vermute die hohe VPN-Last hat dazu geführt dass die Accesspoints keine Verbindung zum Wireless Controller in der Zentrale mehr hatten. Ich weiß die Zahl nicht mehr genau, aber wenn sie im Bereich 5-10 Minuten keine Verbindung haben, unterbrechen sie die WLAN-Abstrahlung.

  • 0 in reply to emmosophos

    Hello Emmanuel,

    the Red50 in  the Branch Office connects through standard/split mode to the the central gateway, the central gateway offers the dhcp-service for the red-net. The central gateway is a esxi-vm with 2 VCores (Xeon E5-2640) and 4GB Ram.

    The Wlan-AP´s sit behind the Red50 and are bridged into the local "Red-Net", no separate zone.

    Normally, the AP´s work correctly. Only in times when the central gateway has a high SSL-VPN throughput at about 100 MBit or higher the WLAN in the Branch Office times out. (This SSL-VPN-traffic has directly nothing to do with the connection to the Wlan-Branch-Office, it´s caused by other user/site2site-connections).

     

    Regards,

    Andre

     

     

     

  • 0 in reply to JosefBergmann

    Hallo Josef,

     

    danke für die Info. Gibt es die Möglichkeit den Wlan-Control-Traffic der AP´s gegenüber dem normalen SSL-VPN-Verkehr evtl. zu priorisieren? Das wäre bei Deiner Erklärung wohl die einzige Lösung...

     

    Gruß,

    Andre

  • 0 in reply to Andre Musso

    Hallo Andre,

    ja eine Traffic Policy wäre IMHO der richtige Ansatz. Startpunkt sind die Menüs in "Interfaces & Routing" > "Quality of Service". Lies Dir dazu mal die Hilfe durch und vielleicht den KB-000034234.

    Bevor du aber eine spezielle QoS-Policy für den AP-Controller einrichtest, schalte einfach mal für das betreffende WAN- und RED-Interface den QoS-Service ein (im Status Reiter) und aktiviere bei "Edit" alle Optionen und setze die max. möglichen Bandbreiten. Meist hilft das schon, das der Traffic am RED damit "fairer" behandelt wird.

  • 0 in reply to Andre Musso

    Hallo Andre,

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

    It would be interesting to watch top at the command line when the SSL VPN is carrying so much traffic.  My guess is that you would see very high %sy and that you need to allocate more RAM to that VM.

    MfG - Bob (Bitte auf Deutsch weiterhin.)

  • 0 in reply to BAlfson

    Bob hat Recht, zuerst sollte man prüfen ob die Firewall in der Zentrale nicht ein Resourcenproblem hat.