Alarms are seen on NSX UI with Event type "Remote Logging Server Error" with description:
Log messages to logging server <FQDN>@<Port Number>@TCP cannot be delivered possibly due to an unresolvable FQDN , an invalid TLS certificate or missing NSX appliance iptables rule.
NSX version is 4.2.x, less than 4.2.4.
Alarms repeatedly get triggered and get resolved in the NSX Manager UI, these can be for Managers and edge nodes.
It may seem the alarms and errors started showing after an NSX upgrade. This is because the NSX version 3.x and 4.1.x versions are not impacted by this problem, and only may hit the issue after upgrading to 4.2.1.x or later versions.
The error can be seen in /var/log/syslog.log
/var/log/syslog:2025-06-18 ######## MONITORING [nsx@### alarmState="OPEN" comp="nsx-manager" errorCode="MP701099" eventFeatureName="audit_log_health" eventSev="CRITICAL" eventState="On" eventType="remote_logging_server_error" level="FATAL" nodeId="#####" subcomp="monitoring"] Log messages to logging server #########@######@UDP cannot be delivered possibly due to an unresolvable FQDN, an invalid TLS certificate or missing NSX appliance iptables rule.
Clearing of the message can also be seen in the logs:
2025-06-18 ######## [nsx@#### comp="nsx-manager" subcomp="nsx-sha" level="CRITICAL" eventFeatureName="audit_log_health" eventType="remote_logging_server_error" eventSev="critical" eventState="Off" Configuration for logging server #########@#####@UDP appear correct.
Checking FQDN of the destination logging server on the manager/edge is resolvable using, getent, nslookup, ping or dig commands:
As admin user, check configured logging server:
get logging-servers
Use the FQDN returned for the below commands, as root user:
getent ahosts <fqdn_mentioned_in_alarm>
nslookup <fqdn_mentioned_in_alarm>
ping <fqdn_mentioned_in_alarm>
dig <fqdn_mentioned_in_alarm>
The port numbers are confirmed to be accessible from NSX manager/edges:
nc -zv <fqdn_mentioned_in_alarm> <port_from_alarm>
Using tcpdump on the manager/edge as root user, we see syslog packets leaving to the destination syslog server:
tcpdump -i eth0 host <syslog-server-ip>
Check if the syslog has a configured IPTABLES rule, as root user run on manager/edge:
iptables -L OUTPUT --line-numbers
You should see results showing an ACCEPT rule for UDP syslog, example below:
132 ACCEPT udp -- anywhere anywhere udp dpt:syslog owner UID match syslog
Delete and re-add of the syslog server as admin user on manager/edge does not resolve the issue:
Remove:
del logging server <ip/fqdn:<port> proto udp level <log-level>
Add:
set logging-server <ip/fqdn> proto udp level <log-level>
Packet capture as root user on the manager/edge management port shows syslog traffic leaving the edge and going to the configured syslog server, sample packet capture:
tcpdump -i eth0 ip dst <syslog-server-ip> dst port <port_from_alarm>
This is a known issue impacting VMware NSX. If corresponding IP address of the logging server's FQDN changes, this results in NSX nodes incorrectly using the previous IP in the nodes' iptables rules.
This issue is resolved in NSX 4.2.4 and newer available via Broadcom Support Portal.
Workaround
del logging-server <hostname-or-ip-address[:port]nsx> get logging-servers/config/vmware/nsx-node-api/syslog/ directory and check if there is a file named exporter_firewall_rules file. If this file exists, then delete this file by using command:rm -rf /config/vmware/nsx-node-api/syslog/exporter_firewall_rules"eventType="remote_logging_server_error" eventSev="critical" eventState="On" Log messages to logging server <FQDN>@99999@TCP cannot be delivered possibly due to an unresolvable FQDN, an invalid TLS certificate or missing NSX appliance iptables rule" , then the port number is 99999. [Here 99999 is a random port number used as an example ]iptables -L OUTPUT --line-numbers | grep 99999 1 ACCEPT udp -- anywhere <fqdn> udp dpt:99999 owner UID match syslogiptables -D OUTPUT 1iptables -L OUTPUT --line-numbers | grep 99999 " and then do the deletion if there are multiple 99999 entries. iptables -L OUTPUT --line-numbers | grep 99999 " every time and then perform the next deletion.