Hello - 

Existing install, new problem. As of yesterday (4/15/2026), I am receiving notifications that my EISY is offline, and then back online with a distinct pattern. The offline events occur at :26 past the hour, and then on-line event occurs at :56 past the hour. The portal shows the ISY disconnected during these windows.

I setup a continuous ping to the EISY locally and do not see any drops during these windows, and Internet access is uninterrupted at the house. I checked for possible duplicate IP addresses and it doesn't seem to be a problem. I've rebooted to no effect, and I am on the latest firmware.

Any ideas on what might be happening, or ways to troubleshoot?

Maybe ssh into said eisy and run a ping out to the UD portal and see if maybe the path that it’s taking is troubled?   
 

Is the eisy connected to a different switch maybe or AP than your phone or other things?

I will try this when I get home.
I’ve never used the command line on EISY. Assume SSH to IP and use local user/pass? Any special syntax for sourcing pings? 
TY

27 minutes ago, walkman9999 said:

I will try this when I get home.
I’ve never used the command line on EISY. Assume SSH to IP and use local user/pass? Any special syntax for sourcing pings? 
TY

Command to access your eisy (from a C:\ prompt) is:

ssh admin@eisy.local

I'm unable to ping "my.isy.io" (which resolves to a number of AWS IPs) from the EISY console, but also not able to ping it from my PC so I believe it doesn't respond to pings per a policy. 

I am seeing that during the "outage" pings to the Internet (8.8.8.8) from the CLI on the EISY fail. During this time I see other requests from EISY (the pings, as well as NTP and DNS) leaving the local FW, but there are no replies. I am able to ping the EISY locally and it responds.

What I *don't* see during the outage is the EISY sending any 443 traffic to the AWS IPs of my.iso.io. When things are functioning, those requests are sent every few minutes. It is as if the IESY stops trying to communicate with the portal(s).

After about 30 minutes, the EISY returns to normal. The pings to 8.8.8.8 start working and a few minutes later the SSL comms to the portals begins again, at this point and the EISY shows as on-line" and "registered".

This repeats aver 30 minutes or so for the last 24 hours. 

* EDIT: I've opened a ticket with support. 

Attached:

 - Screenshot of the notifications I'm receiving

- Screenshot of FW log showing approx 30 minute gap in outbound comms from EISY to my.isy.io

Edited March 16Mar 16 by walkman9999
Added a note saying I've opened a ticket with support

I would try turning off any stateful inspection you might have for the EISY via the PAN (Palo Alto).  We're a PAN shop at work - and I know it will scrutinize traffic very much and sometimes tooo much.  Since it's is unable to reach the internet it likely doesn't send the traffic out to the portal (guessing).  So that would explain why when it's unable to ping the internet it stops trying to connect to the portal and not showing any traffic as well.

 

Since you can't reach the internet from the EISY - it obviously won't reach the UD Portal.  Assuming you don't have similar issues with other devices on the network I would see how the traffic is any different - different rules?  Different path?  etc.  I'm leaning towards the PAN getting in the way....

I agree, the PAN should be considered as a suspect. And it is a great point that maybe the EISY stops trying to communicate with the portal when it senses Internet access is unavailable. There is also the suspicious timing of 30 minutes which sounds "FW session like".

I'm looking into the PAN a bit deeper. Initially, no changes in code or policy in many months and never had this problem before. No other devices are exhibiting problems that I see. But I've been burned by the PAN before. Will report back with more info.

 

Unclear what the problem was. I cleared all sessions on the FW and forced EISY to get a new IP address and problem hasn't reoccurred. In hindsight, I should have done these things separately. 

Best bet - a "stuck" FW session or misapplied APP-ID (typical PAN stuff), or a duplicate IP address.

Thanks for help troubleshooting.