Network Requirements for Firewalls and Proxies

This page lists the Internet destinations that the OPC Router accesses on its own—licensing, pronubes connection, Solution Gallery—along with the port and purpose. It is intended for the network department and may be shared as is.

Information on which ports the OPC Router uses and which of these must be opened for incoming traffic can be found at Network Ports . Connections made by the plug-ins to connected systems—OPC servers, databases, MQTT brokers—are project-specific and are not included in either of the two lists; you plan these during engineering; see Network Settings .

The OPC Router runs as a Windows service or as a container process. Neither of these inherits the proxy settings of the logged-in user. In networks with mandatory proxy, restrictive firewalls, or TLS inspection, outgoing connections will therefore fail, even though the same address works in a browser on the same computer.

These connections are established by the Web Management service (inray.OPCRouter.Web.Management), which runs continuously in the background—regardless of whether the interface is open.

Outgoing connections

The following table lists the outgoing connections and explains, for each destination, what it is used for and whether it is required for operation.

Destination	Port	Protocol	Purpose	Required/Optional
license.opc-router.com	443	HTTPS (GraphQL)	Online licensing: license verification and activation, see Activating a License in OPC Router	Required
opcrouter.eu.auth0.com	443	HTTPS	Device code login during license activation using a user account instead of a license key	Optional – only for this login method
login.opc-router.cloud	443	HTTPS	B2C login to the license portal (older login method)	Optional – only for this login method
<tenant>.pronubes.cloud	configurable, default 443	HTTPS	pronubes connection: Health Sharing, Project Upload, Connection Targets. Set the address and port under pronubes Connectivity.	Optional—only if “Enable pronubes” is turned on
<tenant>.pronubes.cloud	as above	WSS (persistent WebSocket connection)	Remote management of the router from within pronubes Management	Optional—only if “Enable Remote Management” is also turned on
github.com, codeload.github.com	443	HTTPS	Solution Gallery: Retrieved from the repository OPC-Router/solutions; the download follows a redirect from github.com to codeload.github.com	Optional—only for the default source. If OR_SOLUTION_GALLERY points to a custom source, that source’s address applies.
*.pki.goog, at least c.pki.goog and i.pki.goog	80	HTTP	Certificate validation for license.opc-router.com, login.opc-router.cloud, and <tenant>.pronubes.cloud, issued by Google Trust Services	Required
*.lencr.org, at least ye1.c.lencr.org and ye1.i.lencr.org	80	HTTP	Certificate validation for opcrouter.eu.auth0.com, issued by Let's Encrypt	Required for device code login

Certificate verification via HTTP on port 80

Two characteristics of these targets regularly lead to troubleshooting:

• Port 80 instead of 443. Blocklists and intermediate certificates are delivered as plain HTTP; both are signed by the certificate authority and do not require their own transport encryption. A rule that only allows outbound traffic on port 443 does not cover them.
• **Part of the certificate validation process, not the product itself. The operating system makes these queries when validating the server certificate; the OPC Router does not. If they fail, the error message reports the address of the actual destination—such as license.opc-router.com—not the blocked destination on port 80.

The two subdomains serve different purposes: c. provides the certificate revocation list (CRL), while i. provides the intermediate certificate of the issuing authority. Google Trust Services and Let’s Encrypt no longer operate an OCSP responder; their certificates specify only a CRL distribution point. An OCSP approval is therefore irrelevant for these two authorities.

If your firewall does not support wildcards, allow c.pki.goog, i.pki.goog, ye1.c.lencr.org, and ye1.i.lencr.org individually. The certificate authorities change these prefixes when a certificate is renewed; the wildcard rule remains valid longer.

Licensing of pronubes Edge

Additionally, allow access to license.pronubes.com via TCP port 443—this is used for license activation and license synchronization for pronubes Edge. The certificate verification for this destination is already covered by *.pki.goog. The complete list for pronubes Edge can be found in the pronubes documentation.

Rules for Workstation Destinations

The table above lists only those destinations that the OPC Router accesses itself. This table lists the destinations that are needed only on a workstation with a browser and do not require sharing on the server running the OPC Router.

Destination	Port	Protocol	Purpose
license.opc-router.com, license.opc-router.de, login.opc-router.cloud	443	HTTPS	Access to the license portal and login there. The German interface links to license.opc-router.de, the English interface to license.opc-router.com.
<tenant>.pronubes.cloud	443	HTTPS	Access to the pronubes portal
pronubes.eu.auth0.com	443	HTTPS	Login to pronubes Management
cdn.auth0.com	443	HTTPS	Graphics for the login page
*.lencr.org, at least ye1.c.lencr.org and ye1.i.lencr.org	80	HTTP	Certificate verification for pronubes.eu.auth0.com
*.pki.goog	80	HTTP	Certificate verification for <tenant>.pronubes.cloud and the license portal

These destinations are generally accessible from a workstation with standard Internet access. A separate rule is only necessary if the workstations are also behind an allowlist.

Destinations for Login Providers

Pronubes Management offers the option to log in using a Microsoft or Google account in addition to logging in with an email address and password. The following lists the endpoints for each login provider to ensure that logging in with them works smoothly. These endpoints are only required if these providers are used.

Destinations for Microsoft Login

Destination	Port	Protocol	Purpose
login.microsoftonline.com	443	HTTPS	Microsoft sign-in
aadcdn.msftauth.net, aadcdn.msauth.net	443	HTTPS	Graphics for the sign-in page

Destinations for Google sign-in

Destination	Port	Protocol	Purpose
accounts.google.com	443	HTTPS	Google sign-in
accounts.google.de	443	HTTPS	Google sign-in: country-specific redirect for the German sign-in page. Outside of Germany, a different country-specific domain may be required instead of .de.
gstatic.com, fonts.gstatic.com	443	HTTPS	Fonts for the sign-in page

Proxy Behavior

• A proxy is configured for each service via the environment variables HTTPS_PROXY and NO_PROXY. In the container, pass them just like the other configurable environment variables. , * , and NO_PROXY must contain all internal targets that should not go through the proxy—in particular, HTTP and REST plug-in targets, the redundancy partner, and localhost. This setting applies to the entire process: If an internal destination is missing, the service will also attempt to establish this connection via the proxy.
• A proxy with authentication is not currently supported.

warning

On Windows installations, HTTPS_PROXY does not cover blocked traffic on port 80. The verification is performed there by Windows Certificate Services, which use the system-wide WinHTTP configuration instead of the service’s environment variables. If your network does not allow direct outbound HTTP traffic, the blocklist destinations must also be accessible via the WinHTTP proxy. Check this using netsh winhttp show proxy.

TLS Inspection

If your network uses TLS inspection, the OPC Router requires one of the following:

• an exception to the inspection for the destinations listed above, or
• the certificate from the inspection certificate authority in the local computer’s certificate store—not just in the logged-in user’s certificate store.

Testing Instructions

1. Test the direct path. From the computer running the OPC Router, test both ports—HTTPS destinations on port 443 and blocklist destinations on port 80:

   Test-NetConnection license.opc-router.com -Port 443
   Test-NetConnection c.pki.goog -Port 80

2. Check the TLS handshake, not just the port. An open port does not prove that TLS inspection is allowing the connection to pass through unchanged:

   Invoke-WebRequest https://license.opc-router.com -UseBasicParsing

   Messages such as “The SSL connection could not be established” or “The remote certificate is invalid” indicate TLS inspection or a failed blocklist check, not a blocked port.

3. Check the proxy protocol. If a destination is completely missing from the proxy’s log, the service is not using the proxy—in this case, check its environment variables. If it appears with a block, the rule is missing from the proxy.

4. **Check the status in the product. Check the license status and—if configured—the connection status to pronubes in Web Management.