Gateway licensing traffic originates in the background gateway service, not in the browser or the interactive Windows session. The request leaves that service identity, passes through the Windows network stack, DNS resolution, local security controls, any proxy, and the upstream firewall before reaching the licensing destination. Follow that packet; a browser that reaches the internet proves only the logged-in user's path.
What path must the licensing request follow?
Map the path before changing settings. The licensing page displays the result, but the background service performs the network work. A per-user proxy, authenticated proxy, or user-scoped firewall rule can therefore allow browser traffic while denying the gateway.
| Path element | Reading to take | Pass result | Failure branch |
|---|---|---|---|
| Gateway service | Service state and service identity | Running under the intended account | Correct the service state or account configuration |
| Local interface | Link state, assigned address, gateway, and route | A valid route exists for the destination | Repair the interface, addressing, or route |
| DNS | Resolution attempted from the server | Licensing hostnames resolve | Correct DNS or name-filtering policy |
| Proxy | Proxy settings visible to the service identity | The service has a usable direct or proxied path | Configure service-level proxy access |
| Security controls | Timestamped allow or deny records | Traffic to *.inductiveautomation.com is allowed |
Correct the matching rule or authentication policy |
| Remote exchange | Gateway and OS diagnostic records | The connection completes and returns a response | Inspect name, transport, TLS, proxy, and remote-response failures |
The address, destination port, and connection time must come from a firewall log, proxy log, socket trace, or gateway diagnostic record. Do not build a rule around a guessed host address or port. Host addresses can change, and an incomplete rule may make the licensing check fail intermittently.
Does layer one and IP routing work for the service host?
Layer one first. Read the active interface state, IP configuration, default route, and DNS server assignments on the Windows host. Then compare them with the working gateway on the same network. The reported comparison has a 7.9.10 gateway on Windows 10 showing online, while the purchased gateway reported as 8.02 on Windows Server remains offline.
The working system proves that the network has some route to the licensing infrastructure. It does not prove that the server uses the same interface, route table, DNS answers, proxy, security profile, or service credentials. Record both hosts side by side rather than treating “same network” as identical behavior.
| Comparison | Working host | Offline host | Decision |
|---|---|---|---|
| Platform | Windows 10 |
Windows Server |
Check host-specific policy and service networking |
| Gateway version as reported | 7.9.10 |
8.02 |
Keep version differences visible during diagnosis |
| Licensing state | Online, test/trial not activated | Offline, previously activated once | Diagnose connectivity independently of activation state |
| Address and route | Read from host | Read from host | Continue only after comparing actual values |
| Destination port | Read from logs | Read from logs | Match the attempted connection, not an assumption |
| Test time | Record timestamp | Record timestamp | Correlate each request with network logs |
Can the background service make the same request as the user?
Test from the service context. Interactive browser access uses the logged-in user's credentials and proxy configuration. A Windows service can run under a different account and may receive different proxy, certificate, firewall, and application-control policies.
- Open the Windows service manager and identify the account running the gateway service.
- Record whether the service is running and whether its identity or startup configuration recently changed.
- Inspect machine-level and service-level proxy configuration. Compare it with the proxy used by the interactive user.
- Check whether the proxy requires user authentication. If it does, determine how the service account is authorized.
- Trigger a licensing status check and record the exact time so network and gateway records can be correlated.
If the browser succeeds but no connection attempt appears for the service at the recorded time, investigate the gateway service, its configuration, local name resolution, and host security controls. If an attempt appears and is denied, the denying device and rule identify the next branch.
Where does the packet stop?
The server was tested with firewalls disabled and with a direct internet connection that bypassed another firewall, yet the gateway stayed offline. Those tests reduce the likelihood that the bypassed firewall alone caused the failure. They do not test a per-user proxy, service-account authorization, DNS behavior, endpoint security, machine policy, or a local service failure.
| Observed reading | Meaning | Next check |
|---|---|---|
| No DNS query at the test time | The request stopped before name resolution or used cached data | Gateway service logs, service state, and local resolver behavior |
| DNS query fails | The service host cannot resolve the required name | DNS server response and name-filtering policy |
| Connection attempt is denied | A local, proxy, or upstream control blocked the request | Deny record, matching identity, destination, and rule |
| Proxy requests authentication | The service lacks acceptable proxy credentials or policy | Service-account authorization and service-visible proxy settings |
| Connection starts but the secure exchange fails | The route works; certificate inspection, trust, protocol policy, or endpoint handling interrupts the session | OS, proxy, and gateway diagnostics at the same timestamp |
| Successful response but page remains offline | Transport completed; gateway processing or status refresh failed | Gateway diagnostics and a controlled service/page refresh |
Ask IT to filter firewall and proxy logs for blocked access to *.inductiveautomation.com, using the offline server's source address and the recorded test time. A timestamped deny entry is stronger than a general statement that internet access is permitted.
How should the resolving branch be applied?
- Restore normal firewall placement after testing; retain a controlled, logged path.
- Identify the gateway service account and the network policy applied to it.
- Give that service identity the required proxy authorization or machine-level network path.
- Create or correct the outbound rule using the destination hostname pattern
*.inductiveautomation.comand the destination details observed in logs. Avoid fixed addresses unless the responsible network policy explicitly requires and maintains them. - Correct DNS, endpoint security, certificate inspection, or trust configuration only when the corresponding diagnostic record identifies that layer.
- Restart or refresh only the component required for the changed setting, then trigger a new licensing check.
Changing several layers at once destroys the diagnostic signal. Apply one resolving change, repeat the same request, and compare the new trace with the baseline. Also keep activation separate from reachability: the working 7.9.10 test/trial gateway was not activated but still reported online.
How is the repair verified?
Verify from the originating service through every hop. At one recorded timestamp, trigger the licensing check and confirm that the service produces a DNS lookup or connection attempt, the proxy or firewall permits it, the remote exchange completes without a local security error, and the licensing page changes from offline to online.
Repeat the check after the service and server return to their normal operating configuration. A result obtained only while controls are disabled is a test condition, not a verified repair.
FAQ
Why does the gateway say offline when Windows has internet?
The browser and gateway service can use different identities, proxy settings, and firewall policies. Trace a licensing request from the background service instead of using browser access as the connectivity test.
Why does one gateway connect on the same network while another does not?
The working 7.9.10 gateway runs on Windows 10, while the offline 8.02 gateway runs on Windows Server. Compare each host's interface, route, DNS, proxy, service account, and security policy.
Why did bypassing the firewall not make the gateway online?
The blockage may be on the server or tied to the service identity, DNS, proxy authentication, endpoint security, certificate handling, or gateway processing. Correlate a fresh request with local, proxy, and upstream logs.
Why should IT search for *.inductiveautomation.com?
The wildcard identifies the stated licensing destination family without guessing a fixed address. Search allow and deny records using the server source address and the exact test timestamp.
How do I verify the gateway licensing fix?
Trigger the check under normal firewall and proxy conditions, confirm the service's request is allowed through each logged hop, and verify that the licensing page reports online.