Licence Server

Diagnosing VPN MTU Issues with Licence Server

Modified on: Fri, 24 Jul, 2026 at 12:30 PM

Symptoms

This article explains how to diagnose Arden Licence Server connections that work on the office network but fail, hang, or time out when a user connects through a VPN.

Typical symptoms include:

The Arden application obtains a licence on-site but not remotely.
The Licence Server appears reachable, but licence allocation does not complete, or subsequent handshakes fail to extend the lease period.
Basic port checks or connection tests succeed, but the application later loses the licence.
The problem occurs intermittently through the VPN.

The point at which the connection fails can help identify the likely cause:

The connection fails immediately: Check routing, DNS, firewall rules, the Licence Server service, and the configured ports.
The connection begins but later hangs or times out: Check for an MTU or packet-fragmentation problem.

Cause

MTU is the largest network packet that can cross a connection without being divided into smaller packets.

Standard Ethernet commonly uses an MTU of 1500 bytes. VPN protocols add their own headers to each packet, reducing the space available for the original traffic. The effective MTU through the VPN may therefore be lower than 1500 bytes.

Normally, when a packet is too large, the network returns an ICMP message telling the sender to use a smaller packet. If a firewall or VPN gateway blocks this message, the oversized packet may be silently discarded. This is sometimes called an MTU black hole.

An MTU black hole can produce misleading results:

Small connection and authentication packets pass successfully.
Ping, port, or basic connectivity checks may appear successful.
Larger Licence Server responses are discarded.
The application hangs or times out instead of displaying a clear connection error.

Arden Licence Server uses a TCP connection, using port 3000 by default, together with a configured range of UDP ports. Larger encrypted licence and settings responses may be more affected by an undersized VPN path than the smaller packets used when the connection is first established.

Other possible causes include:

The Licence Server hostname does not resolve through the VPN.
Split tunnelling sends Licence Server traffic outside the VPN.
TCP port 3000, or the configured alternative, is blocked.
One or more required UDP ports are blocked.
The VPN does not include a route to the Licence Server network.
The Licence Server address is configured incorrectly.
The Licence Server service is unavailable.
VPN latency or packet loss causes the request to time out.

Note: Arden Licence Server does not require one fixed MTU value for every environment. The correct MTU depends on the VPN protocol, network path, and any additional encapsulation used by the customer’s network.

Solution

1. Identify how the connection fails

Ask the user to attempt the affected licence operation and observe the result.

If the application displays an immediate connection refusal or cannot find the server, continue with the routing, DNS, service, and port checks.
If the application starts connecting but then hangs or times out, continue with the MTU test.

Also confirm whether the same device can obtain a licence while connected directly to the office network.

2. Confirm basic Licence Server connectivity

From the affected VPN-connected device, confirm that:

The Licence Server hostname resolves to the expected IP address.
The VPN provides a route to the Licence Server network.
The Arden Licence Server service is running.
TCP port 3000, or the configured alternative, is allowed through the VPN and firewalls.
The configured Licence Server UDP port range is also allowed.
Split tunnelling does not route the Licence Server connection outside the VPN.

Arden Licence Server - TCP/IP and UDP Ports

A successful TCP port test does not confirm that every required UDP port is available, or that larger packets can cross the VPN.

3. Test the path MTU

On the affected Windows device, open Command Prompt and run:

ping -f -l 1472 <licence-server-IP-address>

Replace <licence-server-IP-address> with the Licence Server’s IP address.

The options mean:

-f prevents the packet from being fragmented.
-l 1472 sends a 1472-byte ICMP payload.
Adding 28 bytes for the IPv4 and ICMP headers gives a total packet size of 1500 bytes.

If the command reports that the packet must be fragmented, or the request repeatedly times out:

Reduce the payload by 10 bytes.
Run the command again.
Continue reducing the value until the request succeeds reliably.
Increase the value in smaller increments to find the largest successful payload.
Add 28 bytes to that payload value to estimate the IPv4 path MTU.

For example:

Largest successful payload: 1372 bytes
IPv4 and ICMP headers: 28 bytes
Estimated path MTU: 1400 bytes

Note: Test the Licence Server address where possible. Testing only the VPN gateway may not cover the full network path between the client and Licence Server.

4. Interpret the result

Full-size packets succeed reliably: An MTU problem is less likely. Continue checking the configured UDP range, routing, DNS, Licence Server logs, latency, and packet loss.
Packets only succeed at a lower size: This strongly indicates that the VPN path has a lower MTU.
All ping tests time out: ICMP may be blocked. Do not assume that the MTU is correct or incorrect from this result alone.

The customer should also retest the actual licence operation. Some networks treat ICMP and application traffic differently, so a successful ping test does not always prove that licence traffic will succeed.

5. Correct the VPN MTU

The customer’s IT team should apply one of the following network changes:

Set the VPN client adapter MTU to the measured path MTU.
Set an appropriately lower MTU on the VPN tunnel or gateway.
Enable TCP Maximum Segment Size (MSS) clamping on the VPN gateway or router.
Correct any firewall rule that blocks the ICMP messages required for Path MTU Discovery.

An MTU of approximately 1400 is commonly used as a starting point for some VPN configurations, while connections with additional encapsulation may require a lower value. The measured path MTU and the VPN supplier’s guidance should take priority over a general example.

Warning: MTU and MSS changes affect network behaviour. They should be made by the customer’s IT team through its normal network change and testing process.

6. Retest the Licence Server connection

After applying the network change:

Disconnect and reconnect the VPN.
Confirm that the Licence Server hostname still resolves correctly.
Open the affected Arden application.
Perform the licence checkout or operation that previously failed.
Repeat the test several times.
Confirm that both small and larger Licence Server responses complete successfully.

Test the actual Arden licence workflow rather than relying only on ping or port checks.

Still Not Working?

If full-size packets pass but the application still fails, investigate the other VPN connectivity requirements:

Confirm the TCP port configured for Arden Licence Server.
Confirm the complete UDP port range configured on the Licence Server.
Check inbound and outbound firewall rules.
Check split-tunnel and static-route configuration.
Test hostname and IP-address connections separately.
Review the Licence Server and VPN logs for the same timestamp.
Check for packet loss or unusually high VPN latency.

Collect the following information before escalating the issue:

The exact error message or description of where the application hangs.
The affected Arden product and version.
The Arden Licence Server version.
The configured TCP port and UDP range.
Whether licensing works on the office network.
Whether the failure is immediate or occurs after connecting.
The VPN product, protocol, and client version.
The largest successful unfragmented ping payload.
The configured VPN adapter MTU.
Licence Server, firewall, and VPN logs.
A timestamp for a failed attempt, including the time zone.

Where the customer’s security policy permits it, a packet capture may help determine whether larger packets are fragmented, silently discarded, reset, or left unanswered.

Note: Remove licence keys, passwords, public addresses, customer data, and other sensitive information before sending logs or packet captures to Arden Support.