Is anybody else using StrideLinx VPN from AutomationDirect along with Ignition Designer? If so, do you have issues with gateway connection dropping during Designer sessions? Are there specific settings for Designer or for the VPN that you’ve found to work?
I’m on my 4th development now using Ignition Perspective. I love pretty much everything about the platform **except** that we use StrideLinx VPNs as our standard for remote access and Designer seems nearly unusable over these VPN’s. I can connect to the gateway fine, I open a Designer session and then I get maybe a minute of editing, if I’m lucky, before I get the Gateway Connection Lost message and everything freezes up. If I’m also online with a PLC on Studio 5000 at the same time, I will also lose that connection. Basically the entire VPN connection goes down and I can’t connect to any remote devices.
Designer Output Console messages I can provide if they would be helpful but basically it’s a communication timeout over and over again.
Sometimes the connection recovers after a few minutes. Designer will reconnect and I get another 30-60 seconds of editing time before the connection drops again. Same result if I manually disconnect and reconnect the VPN.
This issue ONLY occurs when using Designer over VPN. Connecting to the gateway, opening Workstation or a project session in a web browser all work fine and there are no issues over the VPN. Using Designer if I’m on site I have no issues. This issue is the same across 3 customer sites in different parts of the US.
StrideLinx VPNs are all connected via ethernet hardline, no Wi-Fi. Running StrideLinx firmware 3.28 and Ignition Versions 8.1.45 and 8.1.48. I have tried messing with a bunch of the StrideLinx settings already to try and fix this but maybe I’m overlooking something…
The pretty definitively points the finger at your specific VPN.
The most common problem I see with VPNs in general is poor handling of MTU. You probably need to change your workstation's max MTU to allow for VPN headers, as it is likely your setup is not automatically determining it correctly.
I use the StrideLinx VPN gateways without any Designer problems. I don’t make any changes to the VPN’s default settings. The times it hasn’t worked was caused by a bad internet connection. Is it possible that you have a firewall between the StrideLinx WAN port and the Internet that is causing the problem?
To minimize losing any work-in-progress, especially for any intermittent or unreliable connection, I recommend remoting into a machine with a more direct access to the GW and running a Designer session from there. Some work in your session may not be salvageable on reconnect (testing in script console, etc.).
To be clear, this issue with Designer occurs even if I’m not using the VPN connection for anything else at the time. That said, I agree it’s likely a VPN issue and something that Designer specifically doesn’t like about it.
That’s an interesting thought on MTU. I will be onsite at one customer in a couple of weeks and can try pinging different packet sizes in and out through the VPN to see if there’s a max size before it gets fragmented.
I don’t believe it’s a firewall problem except maybe the firewall on the actual workstation Ignition is installed on…other than port 8088/8089 or whatever the gateway is using, do you have any other inbound/outbound rules set up to allow Ignition to communicate? Do you allow any specific ports through the VPN or like you said is it really just out of the box default settings?
Gotcha. Not that I’m aware of but I can check with customer’s IT provider to see if they have a smart box installed.
Again the issue is the same at 3 different sites and only with Designer. Is there something specific about how Designer sends/receives data that would trigger a disconnection with this kind of device, vs. PLC traffic, other HMI’s and Perspective sessions that have not caused a connection issue?
The designer runs a mix of conventional HTTP (custom payloads) for pure designer operations, while the Perspective workspace is running websocket traffic through JxBrowser.
A true Perspective client will do nearly all custom payloads through websockets, while HTTP only carries common web payloads (javascript, css, media).
I would expect a deep inspection firewall to treat them very differently.