How do I allow the edge gateway through my network firewall? (ports, protocols, server allowlist)

1 Jul 2026
Knowledge

Description

The edge gateway is installed in the machine, enabling users to remotely service the machine when needed, securely.

To grant the edge gateway the access that it requires, changes may be needed in your company firewall.

Ports & protocols
Server allowlist
Additional company firewall settings to review
Tip: Use the IXON Check

Ports & protocols

Below is an overview of all the ports and protocols that the edge gateway may utilize, which can be blocked by the company firewall. Some ports and protocols are only used if specific settings are enabled or configured. Please ask your edge gateway/machine supplier to check which of the mentioned settings below the table are enabled or configured on their edge gateway.

Direction	Source	Destination	Port	Transport	Application
Outbound	Edge gateway	See Servers	443	TCP	HTTPS, MQTT (TLS), OpenVPN
			1194⁽¹⁾	UDP	OpenVPN
			8443⁽²⁾	TCP	HTTPS
			53⁽³⁾	TCP & UDP	DNS
			123⁽⁴⁾	UDP	NTP
			(no port)⁽⁵⁾	ICMP (Echo request)	-

(1) (Optional) Only used when VPN connection type is set to UDP in the edge gateway settings.
(2) (Optional) Only used when stealth mode is activated for connectivity via a censored internet connection (i.e. when the edge gateway is located in China).
(3) (Optional) DNS requests are often handled by local DNS servers. In those cases the listed DNS port can be ignored.
(4) (Optional) Only used when time synchronization method is set to NTP.
(5) (Optional) Only used when more than one connection type is configured (wired, Wi-Fi, cellular)(failover) on an IXrouter3 model.

Server allowlist

Below are various methods to grant the edge gateway the necessary server access. With time, some servers may be removed or added to meet demand. We try to keep these changes to a minimum, but strongly recommend to use one of the below automatic methods. If we add or remove a server, we update the DNS record whitelists and IP lists.

Automatic update method: Single DNS record whitelist (recommended)

If your firewall can handle more than 32 IP addresses per DNS lookup, make an exception in your firewall to allow traffic to all IP addresses in the following DNS record. Doing a DNS request to this domain name will always return an up-to-date IP list of all current IXON servers. Your firewall should re-resolve the domain name once the TTL expires and within an hour your firewall will be up-to-date in the event that a server is either added or removed.

If your firewall can only handle up to 24 or 32 IP addresses per DNS lookup, use the below method with multiple smaller whitelists or whitelist TXT file instead.

Global
This is our global allowlist, recommended for the most optimal user experience.

Global

all.allowlist.ayayot.com

Regional
Alternatively, you can use one of our regional allowlists, but note that the edge gateway will not be able to connect if it's configured to connect to a different region.

North, Central, and South America

all.amer.allowlist.ayayot.com

Europe, Middle East, and Africa

all.emea.allowlist.ayayot.com

Asia and Pacific

all.apac.allowlist.ayayot.com

Additional
Additionally, if your edge gateway/machine supplier uses an IXON "M2M Cloud Cluster", also make an exception for that VPN server's domain name in your firewall. If you're unsure, check with your edge gateway/machine supplier.

examplem2mcloudcluster.rsv.ayayot.com
Please contact your edge gateway/machine supplier for their M2M Cloud Cluster domain name.

Automatic update method: Multiple smaller DNS record whitelists

If your firewall can only handle up to 24 or 32 IP addresses per DNS lookup, like a Barracuda or Palo Alto firewall, make an exception in your firewall to allow traffic to all IP addresses in the following DNS records. Doing DNS requests to these domain names will always return up-to-date IP lists of all current IXON servers. Your firewall should re-resolve the domain names once the TTL expires and within an hour your firewall will be up-to-date in the event that a server is either added or removed.

Each allowlist contains up to 48 total IP addresses, consisting of an IPv4 and IPv6 IP address of up to 24 servers. Your firewall will need to specify which type it is requesting to ensure that only up to 24 IP addresses are returned. Click below for your firewall's details or consult the manufacturer's documentation.

Palo Alto

By default, both IPv4 and IPv6 addresses are requested. Disabling IPv6 Firewalling will result in only IPv4 addresses being requested.

However, if disabling IPv6 Firewalling is not preferred, instead use the below option "IP list TXT file (auto)" in an External Dynamic List.

Global
These are our global allowlists, recommended for the most optimal user experience.

Global

a.allowlist.ayayot.com
b.allowlist.ayayot.com
c.allowlist.ayayot.com
d.allowlist.ayayot.com
e.allowlist.ayayot.com
f.allowlist.ayayot.com
g.allowlist.ayayot.com
h.allowlist.ayayot.com
i.allowlist.ayayot.com
j.allowlist.ayayot.com

Additionally, if failover is configured in the edge gateway, also add the following domain name. If you're unsure, check with your edge gateway/machine supplier.

z.allowlist.ayayot.com

Regional
Alternatively, you can use our regional allowlists, but note that the edge gateway will not be able to connect if it's configured to connect to a different region.

North, Central, and South America

a.amer.allowlist.ayayot.com
b.amer.allowlist.ayayot.com
c.amer.allowlist.ayayot.com
d.amer.allowlist.ayayot.com
e.amer.allowlist.ayayot.com

Additionally, if failover is configured in the edge gateway, also add the following domain name. If you're unsure, check with your edge gateway/machine supplier.

z.amer.allowlist.ayayot.com

Europe, Middle East, and Africa

a.emea.allowlist.ayayot.com
b.emea.allowlist.ayayot.com
c.emea.allowlist.ayayot.com
d.emea.allowlist.ayayot.com
e.emea.allowlist.ayayot.com
f.emea.allowlist.ayayot.com
g.emea.allowlist.ayayot.com

Additionally, if failover is configured in the edge gateway, also add the following domain name. If you're unsure, check with your edge gateway/machine supplier.

z.emea.allowlist.ayayot.com

Asia and Pacific

a.apac.allowlist.ayayot.com
b.apac.allowlist.ayayot.com
c.apac.allowlist.ayayot.com
d.apac.allowlist.ayayot.com
e.apac.allowlist.ayayot.com

Additionally, if failover is configured in the edge gateway, also add the following domain name. If you're unsure, check with your edge gateway/machine supplier.

z.apac.allowlist.ayayot.com

Additional
Additionally, if your edge gateway/machine supplier uses an IXON "M2M Cloud Cluster", also make an exception for that VPN server's domain name in your firewall. If you're unsure, check with your edge gateway/machine supplier.

examplem2mcloudcluster.rsv.ayayot.com
Please contact your edge gateway/machine supplier for their M2M Cloud Cluster domain name.

Automatic update method: IP list TXT file

As alternative method, you can make your firewall regularly and automatically import and use the following TXT file, which will always return an up-to-date IP list of all current IXON servers. Compatibility is firewall-dependent.

Global
These are our global allowlists, recommended for the most optimal user experience.

Global

List containing both IPv4 and IPv6 addresses:
https://allowlist.ayayot.com/ip.txt
List containing solely IPv4 addresses:
https://allowlist.ayayot.com/ipv4.txt
List containing solely IPv6 addresses:
https://allowlist.ayayot.com/ipv6.txt

Regional
Alternatively, you can use our regional allowlists, but note that the edge gateway will not be able to connect if it's configured to connect to a different region.

North, Central, and South America

List containing both IPv4 and IPv6 addresses:
https://allowlist.ayayot.com/amer/ip.txt
List containing solely IPv4 addresses:
https://allowlist.ayayot.com/amer/ipv4.txt
List containing solely IPv6 addresses:
https://allowlist.ayayot.com/amer/ipv6.txt

Europe, Middle East, and Africa

List containing both IPv4 and IPv6 addresses:
https://allowlist.ayayot.com/emea/ip.txt
List containing solely IPv4 addresses:
https://allowlist.ayayot.com/emea/ipv4.txt
List containing solely IPv6 addresses:
https://allowlist.ayayot.com/emea/ipv6.txt

Asia and Pacific

List containing both IPv4 and IPv6 addresses:
https://allowlist.ayayot.com/apac/ip.txt
List containing solely IPv4 addresses:
https://allowlist.ayayot.com/apac/ipv4.txt
List containing solely IPv6 addresses:
https://allowlist.ayayot.com/apac/ipv6.txt

Additional
Additionally, if your edge gateway/machine supplier uses an IXON "M2M Cloud Cluster", also make an exception for that VPN server's IP address in your firewall. If you're unsure, check with your edge gateway/machine supplier.

examplem2mcloudcluster.rsv.ayayot.com
Please contact your edge gateway/machine supplier for their M2M Cloud Cluster domain name, then resolve it to an IP address (DNS lookup).

Please keep your firewall rule/exception up-to-date by periodically checking whether the resolved IP address of the domain name has changed to maintain optimal remote service accessibility.

Manual update method: IP list

If your firewall is incompatible with all above automatic methods, you'll need to keep your firewall updated manually. Visit the following domain name to get an IP list of all current IXON servers. You can then create exceptions to these IP addresses to grant the edge gateway the access it needs.

Global
This is our global allowlist, recommended for the most optimal user experience.

Global

https://allowlist.ayayot.com/ip.txt

Regional
Alternatively, you can use one of our regional allowlists, but note that the edge gateway will not be able to connect if it's configured to connect to a different region.

North, Central, and South America

https://allowlist.ayayot.com/amer/ip.txt

Europe, Middle East, and Africa

https://allowlist.ayayot.com/emea/ip.txt

Asia and Pacific

https://allowlist.ayayot.com/apac/ip.txt

examplem2mcloudcluster.rsv.ayayot.com
Please contact your edge gateway/machine supplier for their M2M Cloud Cluster domain name, then resolve it to an IP address (DNS lookup).

Please keep your firewall rules/exceptions up-to-date by periodically checking whether the IP list and the resolved IP address of the domain name have changed to maintain optimal remote service accessibility.

Additional company firewall settings to review

Below is an overview of noteworthy company firewall settings that may (un)intentionally interfere with the edge gateway's connections.

Setting	Information
Non-SSL traffic over SSL-ports	The very first package of the VPN connection (OpenVPN protocol, port 443) may be considered unencrypted, because the OpenVPN handshake takes place prior to the TLS handshake. For this reason, an exception may be required on firewall rules that block non-SSL traffic over SSL-ports. Additionally, if the edge gateway model is a SecureEdge or SecureEdge Pro and failover is configured, HTTP requests are periodically sent over port 443 to test if the connection provides internet access. Please ask your edge gateway/machine supplier to check if this is the case. More information in the failover support article.
SSL inspection, SSL decryption, SSL Proxy, Deep packet inspection, Forward Proxy Decryption, or similar	This can decrypt and inspect network communication or check the validity of certificates. The former behavior is similar to a man-in-the-middle attack, which means that something is actively inspecting or can even make changes to the remote connection. As a result, we cannot ensure the security and integrity of the remote connection and it is therefore not established. The latter behavior checks whether used certificates are signed by certification authorities. However, IXON uses self-signed certificates for the VPN connection, if stealth mode is disabled (default). As a result, the company firewall falsely distrusts the certificates and the VPN connection is not established. With stealth mode enabled, certificates from certification authority Let's Encrypt are used instead. Below you'll find information how you can disable this in the most common firewalls. If your firewall manufacturer is not listed, please consult their documentation or contact them directly. Fortinet Under Policy & Objects > Firewall Policy, create a new rule that has Inspection Mode configured with Flow-based (not Proxy-based). For more information refer to the Fortinet documentation. Additionally, under Security Profiles > SSL/SSH Inspection, create a clone for the read-only profile no-inspection. Edit the clone by changing the HTTPS port under Protocol Port Mapping to an unused port, like 58443, to make sure that SSL Deep Inspection no longer takes place for port 443. Enable this cloned profile for the relevant policy. For more information refer to this blog post. Palo Alto Under Policies > Decryption, create a rule of the type ssl-forward-proxy that has the action no-decrypt. For more information refer to the Palo Alto documentation. WatchGuard Create a firewall policy rule that doesn’t have HTTPS-Proxy enabled. For more information refer to the WatchGuard documentation. Zscaler Make an exception for the IXON domains in your SSL inspection policy. For more information refer to the Zscaler documentation.

Setting

Information

Non-SSL traffic over SSL-ports

The very first package of the VPN connection (OpenVPN protocol, port 443) may be considered unencrypted, because the OpenVPN handshake takes place prior to the TLS handshake. For this reason, an exception may be required on firewall rules that block non-SSL traffic over SSL-ports.

Additionally, if the edge gateway model is a SecureEdge or SecureEdge Pro and failover is configured, HTTP requests are periodically sent over port 443 to test if the connection provides internet access. Please ask your edge gateway/machine supplier to check if this is the case. More information in the failover support article.

SSL inspection, SSL decryption, SSL Proxy, Deep packet inspection, Forward Proxy Decryption, or similar

This can decrypt and inspect network communication or check the validity of certificates. The former behavior is similar to a man-in-the-middle attack, which means that something is actively inspecting or can even make changes to the remote connection. As a result, we cannot ensure the security and integrity of the remote connection and it is therefore not established. The latter behavior checks whether used certificates are signed by certification authorities. However, IXON uses self-signed certificates for the VPN connection, if stealth mode is disabled (default). As a result, the company firewall falsely distrusts the certificates and the VPN connection is not established. With stealth mode enabled, certificates from certification authority Let's Encrypt are used instead.

Below you'll find information how you can disable this in the most common firewalls. If your firewall manufacturer is not listed, please consult their documentation or contact them directly.

Fortinet

Under Policy & Objects > Firewall Policy, create a new rule that has Inspection Mode configured with Flow-based (not Proxy-based). For more information refer to the Fortinet documentation.

Additionally, under Security Profiles > SSL/SSH Inspection, create a clone for the read-only profile no-inspection. Edit the clone by changing the HTTPS port under Protocol Port Mapping to an unused port, like 58443, to make sure that SSL Deep Inspection no longer takes place for port 443. Enable this cloned profile for the relevant policy. For more information refer to this blog post.

Palo Alto

Under Policies > Decryption, create a rule of the type ssl-forward-proxy that has the action no-decrypt. For more information refer to the Palo Alto documentation.

WatchGuard

Create a firewall policy rule that doesn’t have HTTPS-Proxy enabled. For more information refer to the WatchGuard documentation.

Zscaler

Make an exception for the IXON domains in your SSL inspection policy. For more information refer to the Zscaler documentation.

Tip: Use the IXON Check

Use the IXON Check to test the network and provide insights. It is unfortunately unable to test everything that the edge gateway does. If all tests pass but the edge gateway cannot connect, it may be rate limited or blocked in the IXON Cloud. Ask your edge gateway/machine supplier to check this and to reset it if it's active. If it then still cannot connect, something in the network settings or company firewall is still preventing the edge gateway from being able to connect.

Title

How do I allow the edge gateway through my network firewall? (ports, protocols, server allowlist)

URL Name

How-do-I-allow-the-edge-gateway-through-my-network-firewall-ports-protocols-server-allowlist

How do I allow the edge gateway through my network firewall? (ports, protocols, server allowlist)

Ports & protocols

Server allowlist

Additional company firewall settings to review

Tip: Use the IXON Check

Introduction

Remote Access

Fleet Management

User Management

Customer Portal

Machine Data

Notifications

Hardware

Open Innovation

Security and Availablility

Release Notes

Knowledge

How do I allow the edge gateway through my network firewall? (ports, protocols, server allowlist)

Article Details

Ports & protocols

Server allowlist

Additional company firewall settings to review

Tip: Use the IXON Check

Properties

Introduction

Getting Started

Remote Access

VPN connection

VPN Client

Web Access

Connect to your machine

Connection details

M2M Cloud Cluster

Fleet Management

Edge gateway registration

IXagent registration

WAN Settings

LAN Settings

Edge gateway firewall

General device settings

User Management

Setup

Invite and manage users

My account

External Identity And Access Management

Customer Portal

Custom login page and homepages

White labeling

Machine Data

Live Data

Historical Data

Data Source protocols

Pages, cards, and reports

Components

AI assistant

Notifications

Alarms & Notifications

Hardware

Edge gateways and accessories

Open Innovation

Custom development

Marketplace

Security and Availablility

Security

Availability

Release Notes

IXON Cloud

Knowledge

Highlighted Articles

Tips

Related Articles