Einleitung
Dieser Artikel listet alle Netzwerk-Ports, die WERBAS//KSR NET auf dem Server-Rechner belegt oder für die Kommunikation mit anderen Systemen benötigt. Die Angaben sind Grundlage für die Firewall-Konfiguration bei Neuinstallation und Betrieb. Die Ports sind in zwei Gruppen aufgeteilt: belegte Ports sind Ports, die der BO-Server auf der Maschine öffnet und auf denen er Verbindungen entgegennimmt. Diese müssen in der Firewall eingehend freigegeben werden. Verwendete Ports sind Ports, zu denen der BO-Server aktiv hinausgeht. Diese betreffen die ausgehende Kommunikation.
Ports, die der BO-Server belegt
Die folgende Tabelle zeigt alle Standard-Ports, die der BO-Server selbst bindet und auf denen eingehende Verbindungen entgegengenommen werden.
Belegte Ports des BO-Servers
Funktion / Rolle |
Default |
Protokoll |
Vergabe im Setup |
Remoting (Client ↔ Server) |
8086 |
TCP/HTTP (.NET Remoting) |
Automatisch bei Neuinstallation; je weitere Instanz +1 |
SignalR (Echtzeit-Push, Fortschrittsanzeige) |
11120 |
HTTP / WebSocket |
Automatisch bei jedem Update; je Instanz eindeutig |
Fusion API (Server-Bind) |
8321 |
HTTP (Kestrel, eingehend) |
Automatisch bei jedem Update; je Instanz eindeutig |
| REST / Cloud-Host | 8085 | HTTPS (HTTP.SYS) | Keine automatische Vergabe; nur eine Instanz pro Maschine |
Hinweis zu Multi-BO-Umgebungen
Laufen mehrere BO-Server-Instanzen auf einer Maschine, müssen alle belegten Ports maschinenweit eindeutig sein. Remoting, SignalR und Fusion API werden vom Setup automatisch hochgezählt. Die erste Instanz verwendet jeweils den Default-Port, jede weitere Instanz erhält den nächsten freien Wert. REST ist die Ausnahme und wird nicht pro Instanz erhöht.
Ports, die der BO-Server verwendet
Die folgende Tabelle zeigt die Standard-Ports, zu denen der BO-Server aktiv Verbindungen aufbaut.
Verwendete Ports des BO-Servers
Funktion / Rolle |
Default |
Protokoll |
Gateway / Cloud-Anbindung (RabbitMQ) |
5672 |
AMQP (ausgehend zur WERBAS-Cloud) |
| WERBAS.blue / Cloud Public-Port | 51893 (Beispiel) | TCP (via NAT / Port-Forwarding) |
Abgrenzung Fusion API und Cloud-Anbindung
Die Fusion API tritt in zwei getrennten Rollen auf, die nicht verwechselt werden dürfen: der eingehende Server-Bind-Port 8321 und die ausgehende Cloud-Anbindung über RabbitMQ auf Port 5672.
Sonderfall Reverse-Remoting
Der klassische Rückkanal für Fortschritts- und Statusmeldungen läuft über Reverse-Remoting. Dabei startet der Client einen eigenen kleinen Server und registriert sich beim BO-Server. Der BO-Server ruft anschließend auf den Client zurück. Der dabei genutzte Port ist nicht konfigurierbar, sondern wird jeweils als freier TCP-Port auf der Client-Maschine gewählt. Firewall-seitig ist relevant, dass dabei eine Verbindung vom Server zum Client entsteht. Restriktive Firewalls oder VPN-Lösungen können diese Richtung blockieren. In solchen Fällen bleibt die betroffene Client-Maske stehen, obwohl die Verarbeitung serverseitig weiterläuft. Dieser Mechanismus wird schrittweise durch SignalR ersetzt, weil dort der Client die ausgehende Verbindung hält und die Kommunikation auch hinter Firewall oder VPN zuverlässig möglich ist.
REST-Port 8085 – Sonderfall Multi-BO
Der REST-Port 8085 ist global fest und wird nicht pro Instanz hochgezählt. Das Betriebssystem HTTP.SYS erlaubt nur eine Registrierung pro Port. Deshalb darf in einer Multi-BO-Umgebung nur eine Instanz als REST-Host laufen. Auf allen anderen Instanzen muss der REST-Autostart deaktiviert werden.