itxnc  Ally Member

Yeah my excitement may have been premature. I just assumed I'd see SOME data in the stat screens, but everything is empty. I figured maybe it needed 24 hours to gather information before displaying. But you are right - all I see is the uptime. That's disappointing. I'm not asking for realtime traffic stats, but the basic…

We tried to reinstall, no luck. Checked the security panel in MacOS and didn't see where it was being blocked. We migrated them over to the new IPSec client w/IKEv2 for now (all the other users with this client are Windows). But if we get another Mac user. we'll try the steps in that article. Thanks!

This isn't with the IPSec client. It's with the SSL VPN SecuExtender. Worked great until 13.4.1. Now we get this error. We're trying to convert them over to the Mac IPSec client now.

We just started seeing this same problem on Ventura 13.4 and 13.4.1 Do we need to wait for an Apple fix or is this something Zyxel is looking into? Or will we just need to finally move to the Zero Trust VPN or macOS?

Checked one of our ATP500s and it looks current on the new 5.36.1 firmware so far

Just curious - why would you downgrade before the upgrade. I know that gets you cloud update - but you can manually upload to go right from the lab firmware version. Wonder if that had an impact…

I was skeptical reading the marketing speak about this - but I'm honestly VERY excited about this product. We've deployed Zyxel USG (and now FLEX/ATP) gateways to business clients for years and they love them (as do we). We don't manage them via Nebula because it limits so much in terms of configurability of a USG/FLEX/ATP…

We're seeing the same thing on ATP and Flex w/Gold

Just to give everyone an update - best we can tell this was/is some weird issue on the ISP backend? They supposedly had techs check out the backend equipment when they "saw metrics that concerned them", but never heard one way or another. The problem seemed to dissipate. However, it does still happen, just now it's…

So… this was new (tried to SSH into the router with Putty) CLI via browser worked fine, but this was unexpected… We're on the 2023 WK06 firmware

We will definitely do this. It's possible this was a weird provisioning or headnode issue. After a 2 hour call with the ISP apparently they saw some issues with the headnode metrics/signals so they're sending a tech out to check things on the 'other end' So right now the connection is stable for the first time in days, but…

That's tonight's task. Been on phone with ISP for hours because, of course, since we can't reproduce with a single laptop connected to their modem - not their problem even though the packet loss clearly starts at their x.x.x.1 gateway. Trying to get them to understand that there's clearly some 'trigger' 5-30 minutes after…

We did. Didn't matter.

Gotcha. We switched to the TCP connectivity check instead of ICMP on WAN1, no change. Also had Proxy ARP disabled on the WAN side as well.

Sorry - confused what a ping check from the WAN interface would do or cause in relation to this? I mean we have the connectivity check enabled since we have LTE backup on WAN2. But we've disconnected the LTE backup since they've throttled us now. Disabling the Connetivity Check on WAN1 doesn't do anything in terms of the…