A panel's built-in client fails over VPN while its web page loads because the client's stored target holds the panel's plant-LAN IP, an address the remote session cannot reach. Replace that stored IP with the VPN DNS name, keep the web port in the browser address, and test each path from the remote machine.
When a panel's web page loads over the VPN and its built-in client will not connect, the fault is in the client's stored connection target. The entry was filled in automatically with the panel's plant-LAN IP, an address such as 192.168.1.50 that is valid on site and unreachable from a remote session. The browser got through because you pointed it by hand at the VPN DNS name. The fix is one setting: replace the stored IP in the client's connection entry, shown as EA-CON_IP= in this setup, with the DNS name the tunnel publishes, then connect again from the remote PC. Below are the symptoms, the checks that separate a name problem from a route or port problem, the change that works, and the port numbers kept straight.
Why the web page gets through and the client does not
One panel runs two services. The web server serves the page you open in a browser. The client service is what the built-in client speaks to when it draws the screens. They listen on separate ports: the web page in this setup answered on TCP port 8080, and the client service on TCP port 11102. Web servers answer on TCP port 80 for http and TCP port 443 for https by default, so 8080 is a configured choice, and the port stays in the browser address.
The two services also get their targets from different places. The browser target is whatever you type, and to reach this panel remotely you typed the VPN DNS name plus :8080. The client target is stored: the connection entry was filled in automatically with the panel's actual address, a plant-LAN IP such as 192.168.1.50, and that entry is what failed. A private plant-LAN address routes only inside the plant network, and in this setup the tunnel carried no route to that subnet. The DNS name published for the tunnel resolves to an address the tunnel does carry.
So the two results do not contradict each other. A web page that loads shows its own path works: the name resolves, the tunnel carries TCP port 8080, the web server answers. It is not proof of the client's stored target or route. The phone app's success belongs to its own connection; it does not test the client's entry or TCP port 11102. Each program carries its own target, and which kind of target a given program needs is decided per tool: some remote HMI programming software insists on an IP instead of a DNS name, a difference covered in when remote HMI programming software needs an IP, not a DNS name.
Symptoms and what each one points to
- Web page loads at the VPN DNS name with :8080. The tunnel is up, the name resolves from your remote PC, and TCP port 8080 is open.
- Client downloads and installs from the web page but will not connect. The program is fine; read its stored target next.
- Built-in client cannot connect or times out. In this setup the automatic entry held the panel's LAN IP, 192.168.1.50, and that was the whole fault.
- Phone app connects while the client fails. The app's own target and route work; that result leaves TCP port 11102 and the client's entry untested.
- Browser reaches the panel by IP on site but not from home. The address 192.168.1.50 is plant-LAN only, so the tunnel gives your remote session no route to that subnet.
- Web page loads only when you type :8080 by hand. The web service runs on a configured port here; the port belongs in the browser address, not in the client target.
Checks to run from the remote machine
Run these in order, on the same PC and the same VPN session where the failure happens. All four together take about 5 minutes.
- Read the client's connection entry. Open the built-in client's connection settings and read the target it stores, shown as
EA-CON_IP=in this setup. If the value is the panel's LAN IP, for example 192.168.1.50, the client is asking for an address your session may have no route to. - Resolve the VPN DNS name from that PC. Run a name lookup for the tunnel's name while connected. If the name returns nothing, no client change will help until it resolves, and the fault sits in the tunnel's DNS settings. A server that routes the VPN and answers DNS at the same time has its own documented failure modes, listed in the remote-access server's own troubleshooting documentation for name resolution and connectivity.
- Load the web page again at the DNS name plus TCP port 8080. That confirms the browser path is still good and gives you a clean baseline, usually in under 10 seconds. The web-page path itself is written up in viewing a plant HMI web page from home over VPN.
- Change one thing at a time after those three. If the checks point into the tunnel, work outward hop by hop, the way a port-forwarding failure is tested step by step.
The fix: point the client target at the VPN DNS name
- Open the built-in client's connection configuration on the remote PC.
- Select the connection entry whose target is the panel's LAN IP. The entry is named
EA-CON_IP=in this setup. - Replace the address with the VPN DNS name, in the form
EA-CON_IP=remote.vpndnsname.org. Use the name your tunnel actually publishes;remote.vpndnsname.orgis the example value from the setup this page is built around, not a fixed address. - Save and connect from the same remote PC and VPN session. The name resolves through the tunnel's DNS to the carried address, and the client reaches the client service on TCP port 11102.
- Leave the browser address alone. TCP port 8080 stays in the web page URL. The client target carries the name alone; the web port belongs to the web page, and the client service listens on its own port.
One more reason to prefer the name: if the panel's address comes from a DHCP lease, a reboot can hand out a different address and leave the stored IP pointing at nothing. The separation between a DHCP lease and a DNS name, and why the name is the stable handle, is covered in why PLC DHCP assignment is separate from DNS name resolution.
Example scenario: one press room, one renamed target
Scenario: a press room panel holds the plant-LAN address 192.168.1.50. The tunnel publishes the name remote.vpndnsname.org for it. The web server was moved to TCP port 8080, and the client service answers on TCP port 11102.
From a laptop at home, on the VPN:
| Path | Target stored or typed | Port | Result |
|---|---|---|---|
| Web page | remote.vpndnsname.org, typed by hand | TCP 8080 | Loads: the name resolves and the tunnel carries TCP 8080 |
| Built-in client | EA-CON_IP=192.168.1.50, automatic | TCP 11102 | Fails: no route from the home laptop to a plant-LAN address |
| Built-in client after the rename | EA-CON_IP=remote.vpndnsname.org | TCP 11102 | Connects: the name resolves to the address the tunnel carries |
| Phone app | its own stored entry | TCP 11102 | Already worked |
Carry the two figures through. The web path is remote.vpndnsname.org on TCP port 8080 and it loads in under 10 seconds. The client path is the stored address 192.168.1.50 on TCP port 11102 and it times out after about 30 seconds, because the tunnel carries no route to the plant-LAN subnet. After the one rename, the client connects through the name on TCP port 11102 in about 3 seconds, and the whole check pass, both paths together, takes roughly 5 minutes.
The bookkeeping is two targets and two ports. The browser had the name plus TCP port 8080 and worked. The client had the address 192.168.1.50 and failed. Renaming the target to remote.vpndnsname.org moved the client onto the path that already resolved. One setting changed and both paths passed: the web page at remote.vpndnsname.org:8080 and the client screens drawn over the same tunnel on TCP port 11102.
Recommendation and when to widen the check
Recommendation: When a panel's web page loads over the VPN and its built-in client does not, replace the client's stored plant-LAN IP with the VPN DNS name, the EA-CON_IP= entry in this kind of setup, keep TCP port 8080 in the browser address, and retest from the remote PC. Change firewall or VPN rules only if the correct name still fails to resolve or route.
If the rename does not connect, you hold four facts: the stored target string, the name lookup result, the web page test at the name plus TCP port 8080, and the client result after the rename. Hand those to whoever administers the tunnel; the four results separate a DNS fault from a blocked route or a closed client port in one pass. The tunnel's side of the job, including the DNS names it publishes for each panel, belongs to the VPN router configuration, laid out in setting up a VPN router for remote PLC and HMI access.
Questions
Does the client work with the panel's LAN IP if the VPN routes that subnet?
Yes. If the tunnel maps the plant LAN subnet and permits traffic to the panel, a stored IP target reaches the panel exactly as it does on site. The rename matters when the tunnel gives your remote session no route to that subnet, as in the setup described here, or when the panel's address is leased and changes after a reboot.
Which port goes where once the fix is in?
The web port, TCP 8080 in this setup, stays in the browser address after the DNS name. The client target carries the name alone and reaches the client service on TCP 11102 here, a separate service from the web server. If either service is moved again, change that one port where it lives and retest that path on its own.
What if the tunnel publishes no DNS name for the panel?
Ask whoever administers the tunnel to publish one for the panel or to map the plant subnet for remote sessions. A name that resolves only inside the plant will not work from home; the name has to resolve on the remote PC while the VPN is up. Until one of those two exists, the client has no correct target to hold.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.