Source and time correspond to this connection.
Search for the connection by public IP and time, then use the client, device, region and carrier to identify the source network.
Why a connection was denied. Find the reason at the ingress.
View TLS, connection authentication, client configuration, and admission events for a Gateway. Pinpoint the failure stage, handle sources that fail repeatedly, and remove mistaken bans for legitimate devices.
Learn about event recordsFirst locate the source, then check the failed stage.
Failed stages, viewed separately.
Records distinguish between TLS, connection authentication, client settings and source admission, and show the specific cause. Protocol mismatches and authentication failures can be handled separately.
With connection characteristics, keep investigating.
TLS information may include the version, server name, cipher suites and ALPN. Repeated failures accumulate in the count, making it easier to review connection attempts from the same source.
Blocks and allows, applied to this ingress.
When repeated TLS handshake or admission authentication failures within a short period reach the threshold, the Gateway automatically blocks the corresponding public source. A single rejection may also stem from a configuration issue, so check the cause first and correct the device settings.
If a legitimate source is blocked by mistake, allow it manually in the security events for the corresponding Gateway. A manual allowance establishes four-hour admission and is not overridden by automatic blocking from the same rule; sources that no longer need access can also be blocked manually.
The event result shows how it was handled at the time, while the source status shows the current allow or block setting. After saving, the ingress still needs to sync and apply it, and allowing a source does not replace valid connection credentials.
Business access, investigated from the egress.
The Gateway records the stage at which a connection was allowed or denied. To see the business target that was accessed, query the access records on the final Connector.
Learn about egress access auditing →Frequently asked questions.
If I allow a source manually, will it affect other Gateways?
No. The action applies only to the current Gateway and the selected public source. Other ingresses keep their own source admission settings and security event records.
Does a single rejection mean the source is attacking?
Not necessarily. TLS issues, authentication problems, client protocol errors or misconfiguration can all cause a rejection. Handle it according to the stage and reason; automatic blocking applies to sources that reach the threshold of repeated failures within a short period.
After unblocking, does the device no longer need connection credentials?
They are still required. A manual allow only grants source permission at the current ingress; it does not fix the device protocol or replace a valid connection configuration. If switching networks changes the public source, you must also request admission again from the new network.