Send email alerts from an HMI behind a VPN router

The alarm fires, the email action runs, and the inbox stays empty. That is the classic picture in a vision cell behind an industrial VPN router: an HMI, a PLC, code readers and cameras share the cell LAN, and one router handles NAT, the firewall and the service VPN. The send almost never fails inside the HMI; it fails at the first hop, where most such routers drop unsolicited LAN-to-WAN traffic by default. This page gives you the failure signatures to look for, the two settings that make the send work, a timing budget for one alert, and the checks that keep the path alive after commissioning. The same recipe applies when the sender is the cell's controller instead of the HMI.

What the symptom separates

From the HMI, two failure families look identical. In the first, the TCP connection to the mail relay never completes: the message dies at the router, and no SMTP setting on the HMI can fix it. In the second, the connection completes and the relay refuses the message: wrong port or encryption mode, expired credentials, or a sender domain the relay will not carry. A laptop, the router's rule counter and the relay's send log separate the two in minutes. The tests below follow the probabilities, router rule first and uplink last, and each one ends in a decision about where the fix lives.

Cause 1 in probability: the default outbound drop

An industrial VPN router faces the internet with nothing open. Before a tunnel exists, its firewall passes only the router's own encrypted VPN handshake and drops everything else, which is the posture the vendor guides for this class of device describe. The service tunnel you use for remote support is an outbound connection the router itself makes. That is why remote access works while the HMI's mail dies: tunnel traffic originates at the router, mail originates at the HMI behind it, and the LAN-to-WAN path drops it against the default policy.

Configuration delivery is the second half of this cause. On cloud-managed routers a rule saved locally does nothing until the configuration is pushed to the device, and this catches nearly every first commissioning. If the rule's hit counter stays at zero while events keep firing, the rule is wrong or simply not applied.

The fix takes one line even though the details come later: a LAN-to-WAN allow rule with the cell subnet or the HMI's address as source, the relay's host as destination, protocol TCP and destination port 587. Scope it that way rather than switching on a blanket internet allow, so the cell keeps no more egress than the alerts need; it is the same reasoning as isolating a vision cell network from a busy plant LAN.

Causes 2 to 5, in order

1. SMTP settings mismatch. Port 25 where the relay expects 587, implicit TLS where STARTTLS is required, or no credentials on a relay that demands them. The signature is a TCP connect that succeeds and a session that closes right after the greeting or the STARTTLS exchange. The ports worth knowing:

2. No DNS on the HMI. Static-IP cells get a gateway and lose the resolver, so the relay's host name never resolves. Test with the IP address as a diagnostic only; keep the host name as the setting, because certificates check names.
3. The uplink blocks the port. Nearly every access network and cloud platform blocks outbound 25, and a few also block 465 and 587, rarely. A phone-hotspot test from the same laptop separates the site's access network from the relay. A greenhouse build that runs alerts from behind a locked ADSL uplink shows the relay-service route working where direct sends cannot: greenhouse alerts sent from behind a locked ADSL router.
4. The relay refuses the message. Expired credentials, a sender domain it does not carry, or a bounce after acceptance. The relay's send log answers this family directly.

Tests, in order

Work down the list and stop where the signature changes.

1. Laptop on the cell LAN. Open a plain TCP session to the relay on port 587 with any TCP test tool. A greeting banner within about a second means the path is open; go to step 3. A hang with SYN retransmissions means the drop is at the router; go to step 2.
2. Hit counter on the router rule. Open the firewall section of the router's manager, find the LAN-to-WAN policy, and fire a test event from the HMI. Zero hits while events fire means the rule is not applied or the traffic leaves on another interface; hits with no return traffic mean the drop is downstream of the rule.
3. The HMI's send result. Read the error text, not just the red cross: a connection timeout points at the path, an authentication failure at the relay account, host-not-found at DNS.
4. The relay's send log. An empty log means the message never left the site; a logged rejection names the reason on the page. One engineering write-up shows how much time this saves: send log names which hop fails.

The fix: one allow rule and one relay account

1. In the router's manager, create the LAN-to-WAN allow rule: source the HMI address or the cell subnet, destination the relay's host, protocol TCP, destination port 587.
2. If policy demands the cell stay off the open internet, add a drop rule below the allow that covers the remaining LAN-to-WAN traffic; rule sets match in order, so the specific allow wins.
3. Set the HMI's event email: relay host name, port 587, STARTTLS, the relay account's user name and password, and a sender address on a domain the relay is allowed to send for.
4. Push or apply the configuration to the router and watch the rule counter move.
5. Fire a test event from the HMI itself and confirm acceptance in the relay's log.

The habit to keep is the one you already apply to TCP ports and firewall rules between a vision controller and a PLC: write down the rule, its reason and its account. The next engineer who touches that router will ask.

Worked example: missed code to inbox

Say the cell emails on three consecutive missed codes. The legs and their example inputs: decode 120 ms, because clean 1D codes decode in tens to a few hundred milliseconds on current readers; LAN handoff 5 ms across two switches; HMI scan cycle 100 ms, since panel event engines run 50-250 ms; DNS 30 ms on a working resolver; RTT 40 ms to a regional relay; and 250 ms from queue to acceptance at the relay. Nine round trips carry a STARTTLS submission over TLS 1.3: TCP handshake, TLS, EHLO, STARTTLS reply, inner TLS, AUTH, MAIL FROM, RCPT TO, DATA. TLS 1.2 adds a tenth.

t_pipeline = 120 ms + 5 ms + 100 ms = 225 ms. t_smtp = 9 × 40 ms + 250 ms = 610 ms. t_alert = 225 ms + 30 ms + 610 ms = 865 ms, so the relay accepts the alert about 0.9 s after the third miss.

On a 4G backup uplink at RTT 150 ms: t_smtp = 9 × 150 ms + 250 ms = 1,600 ms, and t_alert = 225 ms + 30 ms + 1,600 ms = 1,855 ms, about 1.9 s. The mailbox copy lands 2-10 s after acceptance on a healthy relay.

That arithmetic buys a decision: a send that times out at 10 s is blocked, not slow. Do not widen the timeout; run the tests above, because a working path delivers in seconds.

When the sender is the vision controller

Nothing in the recipe changes when the HMI is not the sender. A vision controller is a computer on the cell LAN, so it holds the mail client itself and can alert on what the HMI never sees: a reader heartbeat lost, a reject rate drifting upward, a batch finished. Reader-side triggers come first. Decide what counts as a miss before you count it, with how to judge whether a decode is trustworthy, then let the decode events feed the counter the controller emails. Those results usually reach the HMI over the link you already planned; implicit versus explicit EtherNet/IP messaging is that choice, not this one.

Readers that sit on the cell LAN and feed these events:

The MV-ID3013PM-12M-WBN reads close-in codes with a 12 mm focal length and 1.3 MP resolution on a global shutter, an M12 mount and Fast Ethernet. The MV-ID813M-05S-WBN-SR pairs a 4.9 mm focal length with white light illumination over GigE on an M10 mount.

For the sender itself, one box can run the inspection, the light and the alerting.

The MV-VC2140-128G40-1T runs a compact cell on an Intel N-series processor with 8 GB of memory, four built-in light output channels and two USB 3 ports.

Cells with more camera streams take the MV-VC3301H-128G66, which pairs an Intel Core i3 processor with 5+ LAN ports, PCIe expansion support and a VM6200Pro vision license; the mail path is the same rule and the same relay account.

Prevention: keep the path alive

• Fire a forced test email from the HMI at commissioning, monthly after that, and after every router firmware update; updates reset or reorder policies often enough that the mail test belongs in the update procedure.
• Keep the relay account in the cell's documentation with its owner and expiry; expired credentials are the quiet failure after a healthy start.
• Alert on the path itself: many routers can notify on WAN loss or tunnel state, which turns a dead uplink into an event instead of silence.
• For alarms that must reach a phone while mail queues or stalls, gate the same event to SMS; sending SMS alerts from a PLC through an email gateway shows the gateway pattern.
• Wiring-level checks for the cell live on the systems guides topic page.

When the usual answer is wrong

• The capture shows a completed TCP session and a successful login. The router is innocent; read the relay's refusal. Sender domains that fail alignment get refused or junked, and greylisting defers a first attempt by minutes before a retry succeeds.
• Some alerts arrive, some do not, and the misses carry images. Size the attachment first: a 2,560 × 2,048 pixel mono frame is 2,560 × 2,048 = 5,242,880 bytes, about 5.2 MB raw and a few hundred kilobytes compressed. Public relays commonly cap a message near 20-25 MB, and an HMI that attaches a full frame to every alert fills the queue and the cap; crop or compress before blaming the path.
• Alerts arrive in a burst at boot or mid-morning. That is queuing, not timing: the cell held messages while the path was down and flushed them on recovery. Treat the burst as an outage report and read the router's log for the gap.
• Everything works from the laptop and never from the HMI. The HMI sits on another interface or VLAN, or its gateway is unset; check its network settings before touching the router again.

If the cell that should send these alerts is still on the bench, choose the sender first: the vision controller category lists LAN-port and light-channel counts per model, the fixed code reader finder covers the decode side, and the system configurator pairs controller, cameras and lighting in one pass. For a live path that still will not send, contact the applications team with the router's rule screenshot and the HMI's error text; we read those two first.