Reservierte Ports auf Sophos Firewall prüfen

Sophos Firewall reserviert bestimmte Portnummern für interne Systemdienste. Diese Ports bleiben auch dann reserviert, wenn der zugehörige Dienst nicht verwendet wird. Taucht der gewünschte Port in der Liste unten auf, muss für die lokale Firewall-Funktion ein anderer gewählt werden.

Das ist besonders wichtig, wenn man einen eigenen Port für WebAdmin, User Portal, VPN Portal, SSL VPN, WAF, einen Proxy oder einen anderen Dienst auf der Firewall plant. Die Reservierung ist dabei nur der erste Check: Auch eine nicht reservierte Portnummer kann bereits von einem anderen Dienst belegt sein oder durch Port Sharing unerwartete Zugriffswege öffnen.

⚠️ Ein nicht reservierter Port ist noch keine Sicherheitsfreigabe. Erreichbarkeit, WAN-IP, Protokoll, Administration > Device access, Port Sharing und vorgeschaltetes NAT müssen weiterhin separat geplant und getestet werden. Für weitergeleiteten Traffic kommen passende Firewall-Regeln hinzu; den Zugriff auf lokale Systemdienste steuern sie nicht.

Reservierte Ports in SFOS 22

Die folgende Liste entspricht dem am 4. September 2026 geprüften Stand für Sophos Firewall 22.0. Bereiche schliessen beide Grenzwerte ein.

Sophos veröffentlicht diese Reservierungen als Portnummern und nennt keine protokollspezifische Ausnahme. Deshalb sollte man nicht versuchen, eine Reservierung durch den Wechsel von TCP zu UDP zu umgehen. Ein Dienstneustart oder das Deaktivieren eines vermuteten Features gibt die Nummer ebenfalls nicht frei.

Reserviert, eindeutig oder geteilt?

Diese drei Prüfungen lösen unterschiedliche Probleme:

Beim Kollisionscheck zählt die Kombination aus Protokoll und Port: TCP 8443 und UDP 8443 sind unterschiedliche Kombinationen. Eine Produktreservierung gilt dagegen für die Portnummer selbst.

• Reserviert: Keine lokale Firewall-Funktion kann eine Nummer aus der obigen Liste übernehmen.
• Eindeutig erforderlich: Web admin console und User portal benötigen jeweils einen eigenen Port. Ihre Standardwerte sind TCP 4444 und TCP 4443.
• Port Sharing mit Einschränkungen: WAF, VPN Portal und SSL VPN dürfen sich Portkombinationen nur unter den von Sophos beschriebenen Bedingungen teilen. Nutzt VPN Portal dieselbe Port-Protokoll-Kombination wie SSL VPN, funktionieren die Login-Security-Einstellungen nicht und das VPN Portal wird aus den für SSL VPN erlaubten Zonen erreichbar. WAF muss sich von VPN Portal und SSL VPN mindestens bei WAN-IP, Port oder Protokoll unterscheiden.

Die vollständige Entscheidungshilfe steht unter Port Sharing zwischen WebAdmin, Portalen, WAF und SSL VPN. Die reservierte Liste ersetzt diesen Kollisionscheck nicht.

Einen eigenen Port ändern und prüfen

1. Ist-Zustand und Abhängigkeiten sichern

Vor dem Change notiert man den aktuellen Port, das Protokoll, die verwendete WAN-IP und die in Administration > Device access erlaubten Zonen. Zusätzlich werden vorgeschaltete NAT-/Listener-Regeln, gespeicherte URLs, Monitoring-Prüfungen und verteilte VPN-Profile erfasst. So lässt sich bei einem Fehler exakt auf den vorherigen Zustand zurückkehren.

Die wichtigsten Portfelder liegen hier:

• Administration > Admin and user settings > Admin console HTTPS port
• Administration > Admin and user settings > User portal HTTPS port
• Administration > Admin and user settings > VPN portal HTTPS port
• Remote access VPN > SSL VPN > SSL VPN global settings > Protocol und Port

Ein Kandidat wie TCP 10443 ist nur ein anpassbares Beispiel. Er steht nicht in der SFOS-22-Liste, muss aber trotzdem gegen alle lokal konfigurierten Listener, Port-Sharing-Bedingungen und vorgeschalteten Geräte geprüft werden.

2. Zugriff und Port Sharing vor dem Speichern prüfen

Für den direkten Zugriff auf lokale Managementdienste steuert Administration > Device access die erlaubten Zonen. Eine normale Firewall-Regel kann diesen Zugriff nicht freigeben oder eine Kollision lokaler Dienste lösen. Soll nur ein bestimmter Host oder ein bestimmtes Netz zugreifen, wird statt einer breiten Zonenfreigabe eine Local service ACL exception rule verwendet.

⚠️ Separater Web-Proxy-Pfad: HTTP- und HTTPS-Anfragen vom Web Proxy der Firewall behandelt SFOS als intern, nicht als Anfragen aus der Clientzone. Eine Sperre des Dienstes für diese Zone unter Administration > Device access isoliert diesen Proxy-Pfad daher nicht. Benutzer mit Zugriff auf den Proxy können lokale HTTPS-Dienste wie WebAdmin oder die Portale über diesen Weg erreichen. Das betrifft die Erreichbarkeit, nicht eine Umgehung der Anmeldung oder des SSL-VPN-Tunnelzugriffs. Die Portalübersicht erklärt diesen Device-Access-Sonderfall.

Bei SSL VPN sind ausserdem Override hostname, die WAN-Weiterleitung und vorhandene Clientkonfigurationen zu prüfen. Die globalen SSL-VPN-Einstellungen werden in die importierte .ovpn-Datei übernommen; nach einer Portänderung benötigen betroffene Clients deshalb eine aktualisierte Konfiguration.

3. Positiv, negativ und fachlich testen

Nach dem Speichern wird der eigentliche Dienst getestet, nicht nur ein offener TCP-Port:

1. Aus einer erlaubten Quellzone mit der vollständigen neuen URL oder einer neu importierten VPN-Konfiguration verbinden.
2. Anmeldung beziehungsweise Tunnelaufbau und die benötigte Funktion prüfen.
3. Aus einer nicht erlaubten Zone einen Negativtest durchführen. Besonders bei gemeinsamem Port und Protokoll kontrollieren, dass kein zweiter lokaler Dienst unerwartet erreichbar wurde.
4. Monitoring, Bookmarks und vorgeschaltete Weiterleitungen auf den neuen Wert umstellen und erneut prüfen.

Akzeptiert die Oberfläche den Wert, beweist das nur, dass die Eingabe gespeichert werden konnte. Es beweist weder die externe Erreichbarkeit noch eine erfolgreiche Anmeldung oder VPN-Verbindung.

Die Positiv- und Negativtests für den direkten Zugriff bleiben erforderlich. Können Clients den Web Proxy der Firewall verwenden, wird zusätzlich die vollständige neue HTTPS-URL des tatsächlich geänderten WebAdmin- oder Portal-Dienstes über genau diesen Proxy getestet: aus der tatsächlichen Clientzone und gegen die vorgesehene Zugriffserwartung. Dabei wird dokumentiert, ob der Dienst über den Proxy erreichbar ist und ob dies der geplanten Freigabe oder Sperre entspricht. Ein abgewiesener Direktzugriff beweist keine Isolation dieses separaten Pfades; eine erreichbare Anmeldeseite beweist noch keine erfolgreiche Anmeldung.

4. Bei Fehlern auf den Ist-Zustand zurückgehen

Scheitert die fachliche Prüfung, trägt man in demselben Portfeld den zuvor dokumentierten Port und das ursprüngliche Protokoll wieder ein. Danach werden NAT-/Listener-Regeln, Profile, URLs und Monitoring ebenfalls auf ihre alten Werte zurückgesetzt und die Positiv- und Negativtests wiederholt. Der Rückweg soll den kompletten vorherigen Zustand herstellen, nicht nur irgendeinen erreichbaren Ersatzport.

Verbindungen, welche die Firewall selbst zu Sophos-Diensten aufbaut, sind eine andere Fragestellung. Die benötigten Ziele und Ports stehen unter Ausgehende Sophos-Dienste und Ports freigeben.

Typische Fehler

Der gewünschte Port lässt sich nicht speichern

Zuerst die Portnummer einschliesslich aller drei Bereiche gegen die reservierte Liste prüfen. Danach aktive lokale Dienste und Port Sharing kontrollieren. Ein freier TCP-Socket-Test oder eine normale Firewall-Regel kann eine Produktreservierung nicht aufheben.

Der Port ist nicht reserviert, aber extern nicht erreichbar

Dann liegt der Fehler nicht automatisch an dieser Liste. Administration > Device access, vorhandene Local-Service-ACL-Ausnahmen, WAN-IP, Protokoll, vorgeschaltetes NAT, Providerfilter und den tatsächlich gestarteten Dienst prüfen. Bei SSL VPN muss Override hostname zur von den Clients erreichbaren Adresse passen.

Nach einer Portänderung funktionieren alte Profile nicht mehr

Exportierte VPN-Profile, gespeicherte URLs, Monitoring und Portweiterleitungen können noch den bisherigen Port enthalten. Diese Abhängigkeiten aktualisieren oder für den Rückweg vollständig auf den dokumentierten Altwert zurücksetzen.

FAQ