Connection Issue of External WAF to an Instance inside Azure Cloud

Question

Hello everyone,

I'm reaching out to request guidance and support regarding an issue we're encountering. We are currently unable to receive syslog traffic from our external WAF to one of our log collectors within our Azure network.

At present, we are not using a native firewall solution and are relying solely on Azure Network Security Groups (NSGs). However, it appears that the WAF is unable to establish a connection to the log collector within the Azure environment.

Given this setup, we would appreciate your recommendations on the most optimized and secure setup for this scenario. From what I understand, in other environments, syslog traffic is often sent first to a cloud-hosted firewall, which then forwards the logs to an internal log collector. Unfortunately, this setup isn't feasible in our current environment.

We would like to ask for your insight on any additional configurations or considerations we might be missing—aside from whitelisting the log source IP to the log collector, which we have already implemented.

Thank you in advance for your assistance.

Answer 1

Dear Carl,

Thank you for reaching out with your concern here at Q&A portal. Based on your description, here are some recommendations to troubleshoot and resolve the connectivity issue between your external WAF and the Azure-based log collector

Please verify NSG rules

Ensure the NSG attached to the log collector's subnet or NIC allows inbound traffic on the syslog port (typically UDP 514 or TCP 601-1024, depending on your setup).

Confirm that the source IP of the external WAF is explicitly whitelisted in the NSG.

Check Azure Network Architecture

If the log collector is behind an internal load balancer or private endpoint, ensure routing is correctly configured.

Verify that the log collector’s private IP is reachable from the external WAF’s outbound path (e.g., no NAT/firewall blocking on the WAF side).

Consider Azure Firewall or NVA for Additional Security

Since you’re not using a native firewall, an Azure Firewall or a third-party NVA (e.g., FortiGate, Palo Alto) could help securely forward syslog traffic.

If cost is a concern, a Linux-based VM with IPTables/UFW could act as a minimal forwarding proxy.

Test Connectivity Directly. Temporarily expose the log collector to a public IP (for testing) and verify if syslog traffic arrives.

Use tools like tcpdump for Linux or Wireshark for Windows to confirm if packets reach the VM.

Alternative is Azure Monitor or Sentinel Integration

If the WAF supports it, consider forwarding logs to Azure Monitor or Microsoft Sentinel instead of an on-VM collector for a more scalable solution.

Best regards,

Alex

P.S. If my answer help to you, please Accept my answer

Answer 2

Hi @Carl Dela Cruz

Check the NIC configuration of your log collector VM in the Azure portal. Does it have a Public IP assigned? If it's behind a Standard Azure LB, ensure the Public IP is assigned to the LB's frontend, and you have an appropriate Load Balancing rule or Inbound NAT rule directing the syslog traffic to the collector VM.

Please verify whether you've whitelisted the source IP or not. If yes, please double-check the rule details:

• Source: IP Addresses - Set to the specific Public IP of your external WAF. Avoid using Any or broad ranges, if possible, for security.
• Source Ports: * or Any.
• Destination: IP Addresses - Set to the Private IP address of your log collector VM NIC.
• Destination Ports: Match the required syslog port: 514 for the UDP rule and 6514 for the TCP rule.
• Protocol: Must be set to UDP for the port 514 rule and TCP for the port 6514 rule. Mismatching the protocol will cause the rule to fail.
• Action: Allow.
• Priority: Must be a number lower than the default DenyAllInBound rule (priority 65500) and lower than any custom Deny rules that might otherwise block this traffic. Valid priorities range from 100 to 4096. Assigning a low number ensures these rules take precedence over default denials.

In which level did you associate NSG? Azure allows NSGs to be associated at two levels: the virtual machine's NIC and the subnet within which the NIC resides. When NSGs are applied at both levels, they create a layered security posture, but both must be correctly configured for traffic to pass.

Even if Azure NSGs allow the traffic, the firewall running inside the log collector VM's operating system must also permit the inbound traffic, so configure the OS firewall to allow inbound traffic on the correct port (like 514) and protocol (UDP/TCP) specifically from the source IP address of the WAF.

Make sure the syslog service is installed, enabled, and running on the collector VM. Verify the syslog daemon configuration. It needs to be configured to: Listen for remote logs and listen on the correct network interface and sometimes they default to listening only on 127.0.0.1 (localhost). Listen on the correct port and protocol (UDP/TCP).

Confirm the WAF is configured to send syslog messages to the correct Public IP Address of your Azure log collector and ensure the port and protocol (UDP/TCP) configured on the WAF match what you are expecting and allowing in Azure (NSG, OS Firewall) and on the syslog daemon and is there any UDRs applied to the VM's subnet that might be forcing traffic destined for the internet through an NVA or elsewhere, potentially creating asymmetric routing.

Run a packet capture on the log collector VM's NIC via Azure Network Watcher. Filter for the source IP of the WAF and the destination port (514). This will show if packets are even reaching the Azure NIC level and enable NSG Flow Logs to see if traffic from the WAF IP is being allowed or denied by the NSG rules.

Use this tool to simulate a connection attempt from the WAF's Public IP to your VM's Public/Private IP and port. It will tell you which NSG rule is allowing or denying the traffic.

---

I hope this has been helpful!

Your feedback is important so please take a moment to click 'Accept answer'.

If you still have questions, please let us know what is needed in the comments so the question can be answered.