Peplink InControl Virtual Appliance Firewall Ports: Why Traffic Direction Matters

Author: Ermias Teffera, (CCIE# 70053)

Deploying a Peplink InControl Virtual Appliance (ICVA) behind an enterprise firewall can appear straightforward: identify the required ports, create the firewall rules, and allow the managed devices to communicate with the appliance.

In practice, one of the most common sources of confusion is not the port number itself. It is traffic direction.

A firewall rule can contain the correct port and protocol and still fail if there is confusion about which system initiates the connection, which system is listening on the destination port, and whether observed traffic represents a new connection or simply return traffic from an established session.

Understanding the communication model before implementing firewall policy can significantly simplify deployment and troubleshooting.

The Most Important Point: The Peplink Device Initiates the Management Session

According to Peplink's InControl Appliance documentation, Peplink devices initiate InControl management communication with the server.

The device communicates with InControl at least every 28 seconds to maintain a session. This design allows a Peplink device to establish two-way management communication with InControl even when the device itself is behind NAT.

Therefore, for normal device management, the basic flow is:

Remote Peplink Device → Enterprise Security Controls → ICVA

From the ICVA's perspective, this is inbound traffic.

This is why the Peplink firewall documentation lists the primary device communication ports as inbound to the appliance.

Core ICVA Firewall Ports and Correct Direction

The following represents the key inbound connections to the ICVA documented by Peplink:



Source	Destination	Protocol	Destination Port	Direction at ICVA	Purpose
Managed Peplink Device	ICVA	UDP	5246	Inbound	General device communication
Managed Peplink Device	ICVA	TCP	5246	Inbound	Remote Web Admin / InTouch
Managed Peplink Device	ICVA	TCP	1443	Inbound fallback	Used if TCP 5246 is not reachable
Authorized User/Browser	ICVA	TCP	443	Inbound	InControl web access
Trusted Management Host	ICVA	TCP	4443	Inbound	Appliance control panel
Approved Sources	ICVA	TCP	80	Inbound	Certificate-related HTTP function
Approved Sources	ICVA	TCP/UDP	53	Inbound	Dynamic DNS/certificate-related functions
Peplink Support, when required	ICVA	TCP	2222	Inbound / Optional	Direct remote assistance

Peplink specifically identifies UDP 5246 as device communication and TCP 5246 as communication used for Remote Web Admin.

The official firewall table also states that TCP 1443 is attempted when TCP 5246 is not reachable for Remote Web Admin/InTouch communication.

UDP 5246: General Device Communication

For normal InControl device communication, the managed Peplink device initiates a UDP session toward the ICVA.

The expected flow is:

Peplink Device → ICVA UDP/5246

More precisely:

Source:           Remote Peplink Device
Source Port:      Dynamic/Ephemeral
Destination:      ICVA
Destination Port: UDP 5246
Direction:        Inbound to ICVA

Peplink states that devices initiate the management communication and use UDP 5246 for general communication.

Once the session is established, the ICVA can send traffic back through that communication channel.

On a stateful firewall, that response traffic is normally treated as return traffic for the established session, rather than requiring a separate rule permitting a new connection in the opposite direction.

TCP 5246: Remote Web Admin and InTouch

TCP 5246 is different from UDP 5246.

Peplink documents:

TCP 5246 → Remote Web Admin / InTouch

The expected flow is:

Remote Peplink Device → ICVA TCP/5246

Conceptually:

Remote Device:Ephemeral-Port
        ↓
      TCP
        ↓
ICVA:5246

This is also inbound to the ICVA.

Peplink's firewall requirements identify TCP 5246 as required device communication for Remote Web Admin and InTouch.

TCP 1443: Remote Web Admin Fallback

TCP 1443 should not be treated as a completely separate primary management path.

Peplink documents TCP 1443 as the fallback when TCP 5246 cannot be reached for the applicable Remote Web Admin communication.

The flow is therefore:

Remote Peplink Device → ICVA TCP/1443

when the preferred TCP 5246 connection cannot be established.

From the ICVA perspective, this is also inbound.

Why Seeing Port 5246 in a Packet Capture Is Not Enough

One of the easiest mistakes during firewall troubleshooting is filtering for:

udp.port == 5246

and assuming that seeing packets means:

“Inbound UDP 5246 to ICVA is working.”

That is not necessarily true.

Consider this flow:

ICVA:31522 → External-Service:5246

followed by:

External-Service:5246 → ICVA:31522

UDP 5246 appears in both packets.

But notice what happened.

The ICVA initiated the connection using an ephemeral source port, and the remote system's destination port was 5246.

The second packet is simply a response:

Source Port:      5246
Destination Port: 31522

That does not demonstrate:

Remote Device → ICVA:5246

These are completely different traffic flows.

Source Port vs. Destination Port

When troubleshooting ICVA connectivity, do not search only for the number 5246.

Always inspect:

Source IP

Destination IP

Source port

Destination port

Protocol

Session initiator

For example:

ICVA:31000 → External-Service:5246

means:

ICVA initiated a connection to destination UDP/5246.

But:

Remote-Peplink:45000 → ICVA:5246

means:

The remote Peplink initiated a connection to ICVA UDP/5246.

The second flow is the one that demonstrates that the expected inbound device-management path to ICVA UDP/5246 is working.

How to Validate UDP 5246 Correctly

If the requirement is:

Remote Peplink → ICVA UDP/5246

then the packet capture should demonstrate:

Source:           Remote Peplink
Destination:      ICVA
Protocol:         UDP
Destination Port: 5246

A useful Wireshark filter is:

ip.dst == <ICVA_IP> && udp.dstport == 5246

For a specific device:

ip.src == <REMOTE_DEVICE_IP> &&
ip.dst == <ICVA_IP> &&
udp.dstport == 5246

If this produces zero packets, then the expected device-initiated communication is not reaching the capture point.

That is substantially different from seeing:

udp.srcport == 5246

because those packets may simply be return traffic from a connection initiated in the opposite direction.

Validate Remote Web Admin Separately

Remote Web Admin should be tested separately from general UDP device communication.

The relevant device-initiated TCP paths are:

Remote Peplink → ICVA TCP/5246

and, when TCP 5246 is unavailable:

Remote Peplink → ICVA TCP/1443

Useful Wireshark filters include:

ip.dst == <ICVA_IP> && tcp.dstport == 5246

and:

ip.dst == <ICVA_IP> && tcp.dstport == 1443

This distinction matters because a device can have one communication path functioning while a Remote Web Admin-related TCP connection is still failing.

ICVA Also Has Outbound Requirements

Although the primary device-to-ICVA communication is inbound, the appliance itself also initiates connections to external services.

This is a separate traffic category and should not be confused with managed devices reporting to the ICVA.

Peplink documents several outbound service dependencies, including TCP 443 connections used for functions such as remote assistance, device information synchronization, firmware validation, notifications, and certificate-related services.

Peplink also documents outbound:

ICVA → *.peplink.com → UDP/5246

for functions including service-expiration synchronization and FusionHub licensing-related operations.

Therefore, two different UDP/5246 flows can legitimately exist:

DEVICE MANAGEMENT

Remote Peplink
      │
      │ UDP/5246
      ▼
     ICVA

INBOUND TO ICVA

and:

EXTERNAL SERVICE COMMUNICATION

     ICVA
      │
      │ UDP/5246
      ▼
Peplink Services

OUTBOUND FROM ICVA

Seeing the second flow does not prove that the first flow is working.

Inbound and Outbound Are Relative Terms

This is especially important when multiple engineering teams are troubleshooting the same problem.

When someone says:

“5246 is allowed inbound.”

The next question should be:

Inbound to what?

From the ICVA perspective:

Remote Peplink → ICVA:5246

is inbound.

From the remote site's firewall perspective, that exact same session may be considered outbound.

Therefore, firewall requests should avoid vague statements such as:

“Allow 5246 both ways.”

Instead, define the actual flow:

SOURCE:
Managed Peplink Devices

DESTINATION:
InControl Virtual Appliance

PROTOCOL:
UDP

DESTINATION PORT:
5246

SESSION INITIATOR:
Peplink Device

PURPOSE:
InControl device communication

That description is far less ambiguous.

Follow the Packet Through Every Security Boundary

Enterprise environments often contain multiple security controls between the managed device and the ICVA.

A generic architecture might look like:

Remote Peplink Device
        │
        ▼
   WAN / Internet
        │
        ▼
Enterprise Security Controls
        │
        ▼
     Firewall
        │
        ▼
       DMZ
        │
        ▼
      ICVA

If the firewall closest to the ICVA reports:

“We don't see the incoming connection.”

continually changing that firewall's rules may accomplish nothing.

Instead, trace the packet from the source.

At each security boundary determine:

Was the packet received?

What source and destination were observed?

Was NAT applied?

Was the packet permitted or dropped?

Was security inspection applied?

Did the next security device receive it?

The objective is to determine the exact point where the expected packet disappears.

Web Administration Should Be Treated Separately

Peplink documents TCP 443 for the InControl website and TCP 4443 for the appliance control panel.

These administrative interfaces should not automatically have the same source scope as device-management communication.

In particular, Peplink states that TCP 4443 control-panel access should be permitted from trusted addresses only.

A secure architecture should therefore distinguish between:

DEVICE COMMUNICATION
Remote Devices → ICVA

and:

ADMINISTRATIVE ACCESS
Trusted Administrators → ICVA

A Better Enterprise Firewall Model

Instead of requesting:

“Open 443, 5246 and 1443 both directions.”

document the actual application flows.

Initiator	Destination	Protocol	Destination Port	Purpose
Managed Peplink Device	ICVA	UDP	5246	General device communication
Managed Peplink Device	ICVA	TCP	5246	Remote Web Admin / InTouch
Managed Peplink Device	ICVA	TCP	1443	RWA fallback
Authorized Browser/User	ICVA	TCP	443	InControl web access
Trusted Management Host	ICVA	TCP	4443	Appliance control panel
ICVA	Approved Peplink/external services	TCP	443	Required external services
ICVA	Approved Peplink services	UDP	5246	Synchronization/licensing functions

Additional documented services should be enabled only when required for the organization's deployment.

Firewall policies should also restrict sources and destinations according to the organization's security architecture rather than defaulting to broad ANY/ANY rules.

Five Questions to Ask Before Blaming the Firewall

When a managed device is not communicating with an ICVA, answer five questions first:

1. Who initiates the connection?

2. What is the destination port—not merely a port number appearing somewhere in the packet?

3. Does the packet leave the source network?

4. Does it traverse each intermediate security boundary?

5. Does it arrive at the ICVA with the expected destination IP, protocol, and destination port?

Once those questions are answered using packet captures and firewall logs, troubleshooting becomes much more deterministic.

The Key Lesson

When troubleshooting Peplink InControl Virtual Appliance connectivity, don't ask only:

“Is port 5246 open?”

The better question is:

“Is the Peplink device initiating the correct protocol toward the ICVA's destination port 5246, and can we prove that traffic reaches the appliance?”

For Remote Web Admin, extend that question to TCP 5246 and its documented TCP 1443 fallback.

And separately verify the ICVA's required outbound connections to approved external services.

That is the difference between port-based troubleshooting and flow-based troubleshooting.

In complex enterprise networks, understanding the flow is just as important as knowing the port.

ITVue Networks

ITVue Networks provides enterprise network engineering, secure connectivity, network modernization, and cybersecurity engineering support. Our focus is designing resilient network architectures and applying practical, evidence-driven troubleshooting methodologies to complex enterprise environments.

Technical Reference: Peplink InControl 2 Appliance Setup Guide, Version 2.14.3.3.