How to Monitor UAGs for Port Exhaustion in ControlUp

A user is having issues with intermittent connections dropping and was advised to periodically reboot the UAGs due to port exhaustion. Other suggestions and ways to monitor the UAGs for this issue were discussed. There is currently no UAG monitoring available in ControlUp, but it is expected to be added in version 9.2. The discussion also includes a mention of a UAG health check script using the Horizon API, and the upcoming feature of UAG support in version 9.2.

Read the entire ‘How to Monitor UAGs for Port Exhaustion in ControlUp’ thread below:

I’m new to control up for the most part, took an act of congress to get it at our company as we have some old skool mentality of reactive vs proactive. With that said we have 2 UAGs and recently had an issue where users from another company connect into our vdi pool of which others connect to no issues, and they were having issues with intermittent connections dropping or not connecting through App and Web. We isolated this by removing one of the UAGs from the F5 vip and stabilized connections. Another engineer gathered logs from the UAG’s and Ominissa said it was port exhaustion and to just periodically reboot the UAGs. As one in my place would feel, I’m not satisfied with this recommendation and finding it rather difficult to monitor these UAGs from a port exhaustion perspective and seeing if anyone could offer up advise on how to effectively do this please? Thanks

Hi Chad we do have UAG monitoring coming on the Road map but that will most likely be a feature in version 9.2 and I don’t have any ETA on that.

@member is our Horizon/Ominissa guru He may have a suggestion.

But I did some reach for you. (Please do your on reach on the below as well)

When you see intermittent connection failures or drops, and logs indicate port exhaustion, it means the ephemeral port range (usually 49152–65535 on Linux) is being consumed faster than ports are being released.

Common causes:

• Idle TCP connections not being closed properly (session leak).

• Backend servers not responding to FIN/RST.

• Misbalanced traffic on the F5 VIP (one node handling more traffic).

• Too many concurrent short-lived connections.

• System limits (nf_conntrack table exhaustion, TCP_TIME_WAIT sockets, etc.).

You can use SSH into the UAG (root or admin) and check the following:

Ephemeral Port Usage

“`

Show socket usage (LISTEN, ESTABLISHED, TIME_WAIT)

sudo ss -s“`

Look at the TCP section — if you see TIME_WAIT or SYN_RECV counts in the tens of thousands, that’s your smoking gun.

Connections by State

“`

sudo netstat -an | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’“`

You’ll get a summary like:

“`

ESTABLISHED 1250

TIME_WAIT 49000

CLOSE_WAIT 3“`

If TIME_WAIT dominates, your sockets are lingering.

Ways to Monitor:

Lightweight shell script you can use to monitor. But this is not something I have used so i suggest testing ad caution

Schedule via cron every 5 mins:

“`

!/bin/bash

ss -s | grep ‘TCP:’ >> /var/log/portusage.log“`

Then graph with a log shipper or export to your SIEM.

Real-time check

Use:

“`

watch -n 10 "sudo ss -s | grep ‘TCP:’"“`

This lets you visualize port churn live.

Diagnostics Beyond Ports

It’s worth also checking:

A. Conntrack Table

“`

cat /proc/sys/net/netfilter/nf_conntrack_count

cat /proc/sys/net/netfilter/nf_conntrack_max“`

If count ≈ max, increase it:

“`

sysctl -w net.netfilter.nf_conntrack_max=262144“`

Verify Idle Timeouts

Compare UAG TCP timeout settings to your load balancer and backend (e.g., Horizon Connection Server). If F5 or UAG keeps sessions open longer than the backend expects, TIME_WAIT sockets will accumulate.

F5 VIP Load Balancing

Check:

• Are you using least connections or round robin?

• Are session persistence (source IP affinity) settings unevenly distributing sessions?

If one UAG gets sticky traffic, it’ll exhaust faster.

sorry Luke, that chatgpt or whatever answer it is talks nonsense. The uag can officially do up to 2000 connections but is known to start stuttering at a way lower number. At this moment the only thing we have in the tool is security gateway information for sessions and a uag health check script that uses the horizon api. In 9.2 indeed we are adding uag support that will get the uag addresses from horizon and then connect to the uag rest api to gather data.

@member thanks 🙂 why I tag you in just in case I was talking nonsense

keeping me honest

I should have put some smilies in there btw 🙂

Continue reading and comment on the thread ‘How to Monitor UAGs for Port Exhaustion in ControlUp’.  Not a member? Join Here!