Web Forms Firewall Requirements
To use Web Forms in SOCKETWorx, the application server must be able to open an outbound PostgreSQL connection to Azure. This note lists what the network firewall has to permit.
What must be allowed
Web Forms stores its data in Azure Database for PostgreSQL (Central US). It is the only part of SOCKETWorx that connects to this endpoint. If this connection is blocked, every other SOCKETWorx feature continues to work normally, and only Web Forms fails.
Requirements
Each item is individually verifiable. Please confirm them by reference (REQ‑1, REQ‑2, …) so any remaining gap can be identified quickly.
Outbound TCP 5432 to the database endpoint
Permit outbound TCP on port 5432 from the SOCKETWorx application server to ecedesignpostgre.postgres.database.azure.com. This must be open on every firewall between the server and the internet.
| Destination object | Value | Notes |
|---|---|---|
| FQDN — preferred | ecedesignpostgre | Tightest rule. Supported as an address object by Palo Alto, Fortinet and most current firewalls. Survives Azure IP changes automatically. |
| IP range — fallback | 172.173.64.0/18 | Use only if FQDN objects are unavailable. Covers the endpoint as of this note's date; needs periodic review (see REQ‑2 note). |
Microsoft does not guarantee a static public IP for this service: the address “can change during maintenance, updates, or other operational events.” A rule pinned to a single host IP will eventually fail without warning, which is why the FQDN object is preferred.
Outbound DNS resolution
The endpoint is a publicly resolvable DNS name, and the application connects by name rather than by address. The application server must be able to resolve *.postgres.database.azure.com. If the fallback IP range in REQ‑1 is used instead of an FQDN object, schedule a quarterly re‑check of that range.
Permit the PostgreSQL application, not just the port
On firewalls with application awareness — Palo Alto App‑ID, Fortinet application control, Cisco Firepower, Zscaler and similar — the postgresql application must be explicitly permitted on this rule. Opening port 5432 alone is not sufficient: the session is allowed to establish and is then terminated by the application engine.
Exempt the destination from TLS/SSL inspection
Add a decryption exclusion for this destination on port 5432. PostgreSQL negotiates encryption in‑band: the session opens in plain text, the client requests TLS, and the same socket is then upgraded. This is not HTTPS on port 443, and inspection engines commonly mishandle it — the usual result is a reset in the middle of the TLS handshake.
No IPS or threat-prevention reset on the session
Confirm that no intrusion-prevention or threat-prevention signature is resetting traffic to this destination. Because the connection is encrypted database traffic on a non-standard TLS port, it is a common false positive.
TLS 1.2 or higher on the application server
The database server requires encrypted connections and its minimum accepted version is TLS 1.2. A host with TLS 1.2 disabled in Schannel, or restricted to an older protocol or a reduced cipher list, will be dropped during the handshake. The verification script below reports the host's protocol configuration.
Report your outbound public IP addresses
Access is also restricted at the database itself, so ECE Design must add your site's outbound (NAT) public IP addresses to the server's allow-list. Please supply all addresses the server may egress from, including any secondary or failover circuit. Allow-list changes take up to five minutes to take effect.
If these addresses are assigned dynamically by your ISP, connectivity will break each time they change. A static address, or a supplied range, avoids this.
Not required
No inbound rules. The application server always initiates the connection. Nothing needs to reach it from Azure.—Port 6432 is not used. Connection pooling (PgBouncer) is not enabled on this server, so only 5432 is needed.
No IPv6 rules. The database allow-list is IPv4 only.
—No VPN or ExpressRoute. The connection runs over the public internet, encrypted end to end.
Verifying the connection
Run this on the SOCKETWorx application server. It performs the same handshake the application does and stops before authentication, so no credentials are transmitted.
# PowerShell, on the SOCKETWorx application server $server = 'ecedesignpostgre.postgres.database.azure.com' $client = [System.Net.Sockets.TcpClient]::new($server, 5432) $stream = $client.GetStream() # PostgreSQL SSLRequest packet $stream.Write([byte[]](0,0,0,8,4,210,22,47), 0, 8); $stream.Flush() $reply = [byte[]]::new(1); $stream.Read($reply, 0, 1) | Out-Null "SSLRequest reply : $([char]$reply[0]) (expect S)" $ssl = [System.Net.Security.SslStream]::new($stream, $false, { $true }) $ssl.AuthenticateAsClient($server, $null, [System.Security.Authentication.SslProtocols]::None, $false) "TLS protocol : $($ssl.SslProtocol)" $ssl.Dispose(); $client.Close()
A working connection reports SSLRequest reply : S followed by TLS protocol : Tls12 or Tls13. Anything else maps to a requirement above:
| Result | Meaning | See |
|---|---|---|
| TLS protocol reported | Firewall path is correct. | — |
| Fails to connect | Port 5432 blocked, or the destination object does not cover the endpoint. | REQ-1, REQ-2 |
Reply is N | The host reached is not the expected database endpoint. | REQ-1 |
| Fails during handshake, every attempt | Application control, TLS inspection, or the host's TLS configuration. | REQ-3, REQ-4, REQ-6 |
| Fails during handshake, intermittently | An in-path device is resetting some sessions. | REQ-4, REQ-5 |
What users see when it is blocked
In the SOCKETWorx interface, Web Forms actions fail with a message such as “Failed to add items.” The application log records the underlying cause:
Npgsql.NpgsqlException: Exception while performing SSL handshake ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException (10054)
This signature means the connection reached the database and was then terminated as encryption began — the pattern produced by application control, TLS inspection or a TLS version mismatch (REQ‑3, REQ‑4, REQ‑6). A firewall or IPS log entry for the same timestamp will normally identify the device that closed the session, and is the fastest way to resolve it.
Because connections are pooled, the failure can look intermittent: only requests that need to open a new connection are affected, while requests reusing an established one succeed.
SOCKETWorx technical note · Web Forms network access · 25 August 2026Requirements derived from Microsoft's published guidance for Azure Database for PostgreSQL flexible server.