Internet and Network Access

About 12 min read

The 2WinScada web interface controls real equipment. This page describes what the integrator must do before the server is accessed from outside the plant network, and how HTTPS certificates are managed. Setup and the main API provide a hardening baseline; however, network design and account discipline matter more.

Do not publish the server directly

The safest approach is not to expose the server to the internet at all. Put the server behind a VPN (WireGuard, IPsec or the firewall's VPN) or a zero-trust tunnel, so that only authenticated people reach the sign-in page.

Recommended order

1. Put the server behind a VPN or a zero-trust tunnel.
2. If direct publishing is unavoidable, forward only TCP port 443 to the server. See Ports.
3. Use a trusted certificate for the public DNS name. See Certificate and HTTPS.
4. Run Setup with the Internet profile and, if possible, with the SystemAdmin network restriction. See Setup settings.
5. Apply the account, backup and update rules.
6. Run the exposure check and fix all warnings before going live. See Exposure check.

Ports

Port	Purpose	Forward it?
TCP 443	Web interface, API and live data connection (HTTPS)	Yes
TCP 80	With the internet profile, only redirects to HTTPS	Optional

Never forward the following ports to the internet. They are internal ports designed to be used only within the server or on a trusted network:

Port	Service
TCP 7100	Main API service (used through IIS)
TCP 7101 / 7105	Internal service ports
TCP 7102 / 7103	Notification / RecordDevice services
TCP 7106 / 7107	MQTT Publisher / MCP Server
TCP 9000, 9003, 8812, 9009	Archive database (QuestDB)
TCP 1433, UDP/TCP 1434	SQL Server and SQL Server Browser
TCP 3389	Remote Desktop (use only over VPN)
TCP 1883 / 8883	MQTT broker (unless it is deliberately published with its own TLS and authentication)

Ports changed during Setup replace these defaults. Check Windows Firewall as well as the router: an inbound rule in the Public profile that allows all ports defeats the restriction on the router.

Outbound connections

If WhatsApp alarm notifications will be used, allow outbound HTTPS (TCP 443) from the server where the notification service (NotificationService) runs to graph.facebook.com. No inbound connection or port forwarding is needed for this. If the plant network has no direct internet access, provide the outbound connection through a DMZ or a corporate proxy. See WhatsApp Settings.

Certificate and HTTPS

Trusted certificate

• For the public DNS name (for example scada.example.com), obtain a certificate from a commercial certificate provider or use Let's Encrypt with win-acme. Export the certificate as PFX together with its private key.
• During the first installation, provide the PFX file on the wizard's IIS and SSL page with the Use existing PFX certificate option.
• The certificate must cover the primary address and all published additional DNS names. If the primary address is an IP address, this IP must also be in the certificate.
• Do not publish an internet-facing server with a self-signed certificate.

Self-signed certificate

Inside the plant network, the Generate self-signed certificate option can be used. Browsers do not trust this certificate and show a warning. Setup does not add the certificate to the trusted root certificate store of the clients or the server. To remove the warning:

1. Find the certificate's thumbprint in the setup log (%ProgramData%\2WinScada\Logs\setup.log).
2. On the server, open certlm.msc and, under Personal > Certificates, export the certificate with this thumbprint as a .cer file without the private key.
3. In line with the organization's policy, import this file into the Trusted Root Certification Authorities store only on the clients that will access the server.

Do not distribute the private key or the PFX file to clients. If the certificate is renewed, update the trust on the clients as well.

Renewing and replacing the certificate

Setup never replaces a certificate bound to the site; even if a new PFX is given during repair, the existing certificate is kept. Bind the renewed certificate yourself before the old one expires:

1. In IIS Manager, select the 2WinScada site.
2. In the Bindings window, select the https entry and select the new certificate.

If win-acme is used, it can renew and bind the certificate automatically. The same procedure applies when moving from a self-signed certificate to a trusted certificate; afterwards, run Repair with Setup so that HSTS is turned on.

If the bound certificate has expired, repair stops at the pre-check; bind a valid certificate first.

HSTS

The HSTS header, which tells the browser to use only HTTPS, is sent only when the internet profile is on and all public names present a certificate issued by a trusted certificate provider. Setup checks the certificate bound in IIS at every installation, repair and upgrade. With a self-signed certificate, the internet profile does not block the installation, but HSTS stays off and Setup writes a warning to the log.

WARNING

While HSTS is on, browsers do not allow the certificate warning to be bypassed. If the certificate expires, the site does not open. Renew the certificate in time.

Setup settings

The internet access settings are on the wizard's Advanced settings page. The MCP and plain HTTP options are enabled only while the internet profile is selected. During repair and upgrade, these options keep their previous values.

Option in the wizard	Silent installation setting	Effect
Internet profile: harden this server for direct internet access	INTERNET_PROFILE=1	Redirects HTTP requests to HTTPS, prevents the site from being shown inside a frame (iframe) on other sites, makes the main API listen only for this computer (127.0.0.1), and sends HSTS if a trusted certificate is bound.
Publish /mcp on the internet site	MCP_PUBLIC_ROUTE=1	Publishes the MCP endpoint on the internet site. Leave it off unless an AI client outside the network is really needed.
Allow plain HTTP (no redirect)	In the help installed with the product	Keeps plain HTTP access open; HTTPS redirection and HSTS are not applied. Not recommended: credentials are sent unencrypted. The decision to turn it on is the responsibility of the installer and the customer.
SystemAdmin sign-in only from these networks (optional, CIDR)	ADMIN_ALLOWED_NETWORKS	SystemAdmin sign-in is accepted only from the listed networks and from the server itself.

For the SystemAdmin network list:

• Separate the networks with ; or ,; for example 192.168.1.0/24;10.8.0.0/16. Use /32 for a single computer.
• If left empty, the installed value is kept.
• While the list is set, MCP keys belonging to SystemAdmin accounts are rejected from every address.
• If the setup log shows a warning about this list, contact the 2WinScada support team and also restrict access with a VPN or the firewall.

After the internet profile is turned on, clients can connect to the API only through the https://<public name>/api address; move integrations that use the API directly on its internal port to this address. If another portal shows SCADA screens inside an iframe, do not use the internet profile on that server, or provide access over VPN.

To turn on the internet profile on an existing installation, run Repair with the package of the same version, or Upgrade with the package of a newer version. Silent repair example:

2WinScada.Setup.2.10.0.x64.exe /S /MODE=Repair /INTERNET_PROFILE=1 /MCP_PUBLIC_ROUTE=0 /ADMIN_ALLOWED_NETWORKS="10.8.0.0/16"

Give the network list in quotes on the command line.

Protections applied in every installation

Whether or not the internet profile is on:

• External systems access the Notification and RecordDevice services through the main API.
• The website sends security headers and hides the server version information.
• Files uploaded by users are served with a restrictive security policy.
• The QuestDB health endpoint can be reached only from this computer.

Accounts, roles and keys

• Give each person their own account. Give operators the Monitor or Operate role. Give the Editor role only to engineers who design pages; this role can upload files to the website. Give the UserAdministrator role only to the people who manage accounts.
• The initial administrator account created during installation is a SystemAdmin. Use this account only for administration, with a long and unique password (at least 16 characters recommended), and keep the password in a password manager. Create separate Administrators accounts for the customer's administrators.
• Do not use SCADA passwords on other systems. Remove the accounts and API keys of people who leave.
• For API and MCP keys, create a separate key with the smallest role for each client. Delete keys that are not used. Do not send keys by email, and do not put them in screenshots or support tickets.
• Even if read-only monitoring is published, prefer to allow writes and commands from outside only to VPN users.

Account management: User and Group Management.

Browser session

From 2.11 the web interface no longer keeps the session renewal key in browser storage. The key stays in a cookie (HttpOnly) that scripts on the page (including event code) cannot read. The access key is separate for each browser tab; a new tab or a restarted browser opens the session from the cookie on its own. Sessions opened before the upgrade keep working the old way until the next sign-in (see Upgrading).

This change prevents the long-lived renewal key from being copied. While the page is open, scripts on the page (including event code) can read the tab's access key until it expires (4 hours by default) and send requests on behalf of the session. On 2.11 only SystemAdmin accounts can add or change event code; see Event Code.

• HTTPS is recommended. On a page opened over HTTPS the cookie is sent only over an encrypted connection. Over plain HTTP the cookie and the sign-in details travel unencrypted on the network.
• The web interface and the API must be on the same site: the same scheme (http or https) and the same domain name; the port may differ. In the setup that Setup installs, the API is published at the same address as the website and no extra setting is needed. In older installations where the web interface calls the API on another port, open the interface with the name and scheme of the API address; for example, if the API is called by a server name, do not open the interface by IP address. Otherwise the browser does not send the cookie and the session ends at the first renewal. The cookie is not separated by port: if two installations on the same server name but different ports (for example production and test) are open at the same time in the same browser profile, they overwrite each other's cookie and sessions end unexpectedly. Open such installations with different server names or in separate browser profiles.
• There is a single renewal key per account. Every sign-in with an account creates a new key; devices that signed in with the same account earlier lose their session at the next renewal, at the latest when the access period expires (4 hours by default). Signing out invalidates only that browser's key on the server; signing out on a device that signed in to the account earlier changes nothing on the server. For shared kiosk accounts, see Session renewal and shared accounts.
• MCP and API clients are not affected. Sign-in and token refresh calls work as before with the tokens in the body (see REST API).

Backups and updates

• Keep the scheduled configuration backup on; back up the SQL Server database and the QuestDB data folder. Keep at least one copy outside the server and try a restore once. See Backup and Restore.
• Install Windows updates every month and 2WinScada updates when they are released. Internet settings are kept during an upgrade. See Upgrading.
• Keep Windows Defender or the antivirus on. Do not use the server for email or web browsing.
• Use Remote Desktop only over VPN and with Network Level Authentication (NLA).

Monitoring sign-in records

The main API writes sign-in events (successful and failed sign-ins, lockouts, invalid API keys) to its log files. Passwords, codes, tokens and keys are not written to the log. Each record contains the user name and the client address. The event names and details are described in the help installed with the product.

Check the logs every week. Many failed sign-ins from the same address, address lockouts, or sign-ins at unusual hours are signs of an attack; block these addresses in the firewall or switch to VPN-only access.

Exposure check

The installation package contains a read-only script that checks the externally exposed surface of the server. The script changes no settings; it checks open internal ports, firewall rules, the Remote Desktop setting, the certificate and the website publishing. Run the check before going live, fix all warnings and keep the report with the commissioning records. The use of the script is described in the help installed with the product.

Go-live checklist

• [ ] A VPN or zero-trust tunnel is set up, or only 443 (optionally 80) is forwarded.
• [ ] A trusted certificate is bound; the site opens with its public name without a warning.
• [ ] Setup was run with the internet profile; a decision was made on publishing MCP; if there are fixed networks, the SystemAdmin network list is defined and the setup log has no warning about this list.
• [ ] The http://<public name>/ address redirects to HTTPS (or plain HTTP was deliberately left open and this was recorded with the customer).
• [ ] After signing in, the session opens in a new browser tab without a sign-in (the web interface and the API are on the same site).
• [ ] Accounts are personal and have the smallest roles; SystemAdmin is used only for administration; unused accounts and keys are removed.
• [ ] Backups are scheduled and a restore was tried.
• [ ] A test sign-in appears in the log as a successful sign-in with the real client address.
• [ ] The exposure check shows no warnings.