Can Azure Container Apps receive UDP packets?

Question

Can Azure Container Apps receive UDP packets?

Nathan Baker 0

Hiya,

To provide a bit of context, I'm running an Azure Container Apps environment containing two ACAs. One ACA is used for the web application, and the other is solely used for processing jobs from a queue. The jobs being processed are queries to an abundance of game servers, most commonly queried by sending an A2S_INFO packet to the game servers' query port. The query port of these game servers tends to be UDP.

Now I've done some troubleshooting and have verified the following:

Querying the failing game server from within the ACA returns a UDP timeout.
The packet is sent to the game server, and the game server sends a challenge request back to the ACA.
Querying another game server works as expected from within the ACA.
Querying the failing game server on my local machine returns the expected result (so it's not like it's just this game server that's the issue; it's specifically when querying from the ACA).

If anyone has any advice, that would be greatly appreciated.

Thanks,
Nathan

Nathan Baker 0 Reputation points

2026-04-30T10:40:17.3466667+00:00

@Pravallika KV Thanks for your quick response. These have definitely put me on the right path.

So I've set up my NAT Gateway with NSG on my VNet and can confirm that the containers are now showing on the NATs outbound IP.

What I've found strange this time round is that the ephemeral port that the query gets sent from within the ACA is 55593. However, when I am looking for traffic from the outbound IP to 27016 (query port of the server). The port it says it's coming from is 22843.

I feel like this might be part of the problem? If these are out of the usual range of ephemeral, then either the game server firewall or my NSG would block the connection.
Pravallika KV 14,235 Reputation points Microsoft External Staff Moderator

2026-04-30T10:47:44.3366667+00:00
@Nathan Baker , Your container app picks an ephemeral source port (55593) and sends the A2S_INFO to the game server. The NAT Gateway then picks an available port from its own port pool (1024–65535) and rewrites your source port to that (in your case 22843). The game server’s response comes back to your NAT IP on port 22843, and NAT Gateway translates it back to your container.

Why your packets are getting dropped

If your NSG or the game server’s firewall is only allowing return UDP on the “standard” high‐ephemeral range (49152–65535), any SNAT port below 49152 will be blocked.

Your 22843 falls in the lower‐half range (1024–49151), so the response never makes it back.

What you can do:

Update your NSG inbound rules (on the custom VNet) to allow UDP from the game server’s IP on source ports 1024–65535 (not just 49152–65535).

Adjust your game server firewall allowlist to include the NAT Gateway’s public IP and the full SNAT port range you just opened.

(Optional) Add additional public IPs to your NAT Gateway so you get a bigger pool of SNAT ports, reducing port‐reuse and translation pressure.

Verify your NAT Gateway’s UDP idle timeout (default 4 minutes) isn’t too low, if mappings expire before the game server sends back its response, you’ll see drops.

If you absolutely need source‐port preservation for UDP listeners

Consider hosting that piece on Azure Container Instances or a VM where you can bind directly to UDP ports without SNAT.
Pravallika KV 14,235 Reputation points Microsoft External Staff Moderator

2026-05-04T08:36:46.2533333+00:00

@Nathan Baker , Following up to see if the provided answer was helpful. If this answers your query, do click Accept Answer =>Yes, and upvote it. If you have any further queries do let us know
Nathan Baker 0 Reputation points

2026-05-06T08:11:13.6133333+00:00

Hi @Pravallika KV

I wasn't able to get the ACA working as intended, so I'm exploring other serverless functions.

Thanks for the advice, though.

2 answers

Your answer

Nathan Baker 0 Reputation points

2026-04-30T10:40:17.3466667+00:00

@Pravallika KV Thanks for your quick response. These have definitely put me on the right path.

So I've set up my NAT Gateway with NSG on my VNet and can confirm that the containers are now showing on the NATs outbound IP.

What I've found strange this time round is that the ephemeral port that the query gets sent from within the ACA is 55593. However, when I am looking for traffic from the outbound IP to 27016 (query port of the server). The port it says it's coming from is 22843.

I feel like this might be part of the problem? If these are out of the usual range of ephemeral, then either the game server firewall or my NSG would block the connection.
Pravallika KV 14,235 Reputation points Microsoft External Staff Moderator

2026-04-30T10:47:44.3366667+00:00

@Nathan Baker , Your container app picks an ephemeral source port (55593) and sends the A2S_INFO to the game server. The NAT Gateway then picks an available port from its own port pool (1024–65535) and rewrites your source port to that (in your case 22843). The game server’s response comes back to your NAT IP on port 22843, and NAT Gateway translates it back to your container.

Why your packets are getting dropped

If your NSG or the game server’s firewall is only allowing return UDP on the “standard” high‐ephemeral range (49152–65535), any SNAT port below 49152 will be blocked.

Your 22843 falls in the lower‐half range (1024–49151), so the response never makes it back.

What you can do:

Update your NSG inbound rules (on the custom VNet) to allow UDP from the game server’s IP on source ports 1024–65535 (not just 49152–65535).

Adjust your game server firewall allowlist to include the NAT Gateway’s public IP and the full SNAT port range you just opened.

(Optional) Add additional public IPs to your NAT Gateway so you get a bigger pool of SNAT ports, reducing port‐reuse and translation pressure.

Verify your NAT Gateway’s UDP idle timeout (default 4 minutes) isn’t too low, if mappings expire before the game server sends back its response, you’ll see drops.

If you absolutely need source‐port preservation for UDP listeners

Consider hosting that piece on Azure Container Instances or a VM where you can bind directly to UDP ports without SNAT.
Pravallika KV 14,235 Reputation points Microsoft External Staff Moderator

2026-05-04T08:36:46.2533333+00:00

@Nathan Baker , Following up to see if the provided answer was helpful. If this answers your query, do click Accept Answer =>Yes, and upvote it. If you have any further queries do let us know
Nathan Baker 0 Reputation points

2026-05-06T08:11:13.6133333+00:00

Hi @Pravallika KV

I wasn't able to get the ACA working as intended, so I'm exploring other serverless functions.

Thanks for the advice, though.

Answer 1

Hi @Nathan Baker ,

Thanks for reaching out to Microsoft Q&A.

Ingress (listening) in Container Apps only supports HTTP/HTTPS and TCP transports, UDP endpoints aren’t supported for inbound traffic.

Egress (outbound) does allow UDP packets but because ACA uses dynamic outbound IPs and ephemeral port mappings, return UDP traffic can easily get dropped if your NAT/NSG setup isn’t preserving the mapping long enough.

Here’s what you can try:

Integrate your Container Apps environment into a custom VNet
- Follow the docs here: https://learn.microsoft.com/en-us/azure/container-apps/vnet-custom
- This gives you control over routing, NSGs, etc.
Deploy a NAT Gateway on that VNet
- That gives you a stable outbound IP and handles UDP NAT timeouts more gracefully
- Docs: https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/configure-public-ip-nat-gateway
Open NSG rules for the ephemeral UDP port range
- Make sure inbound return packets aren’t blocked by your network security rules
(If you need to host a UDP listener) consider using Azure Container Instances or a small VM instead
- ACI and VMs let you bind to UDP ports publicly

If after VNet + NAT you still see timeouts, double-check:

Which outbound IP your app is actually using (logs will show it)
That the game server allow-lists that IP + the full range of ephemeral ports (default UDP 49152–65535)

Hope this helps!

If the resolution was helpful, kindly take a moment to click on User's image and click on Yes for was this answer helpful. And, if you have any further query do let us know.

Answer 2

Azure Container Apps can send and receive UDP traffic, but only as outbound traffic from the container to external endpoints. Inbound connectivity for apps is HTTP(S)-based; there is no direct UDP ingress to a container app from the internet.

For outbound UDP from Azure Container Apps, networking behaves like other Azure PaaS/container services:

Outbound traffic (including UDP) is SNATed to the environment’s single egress IP (public or via VNet/NAT, depending on configuration).
DNS resolution for outbound traffic relies on Azure recursive resolvers at 168.63.129.16. If a custom DNS server is used in the VNet, that DNS server must forward unresolved queries to 168.63.129.16, and NSGs/firewalls must not block that IP. Misconfigured DNS or blocked access to 168.63.129.16 can cause intermittent failures when reaching external services.

Given the scenario:

Some UDP queries succeed and others fail.
The failing game server sends a challenge back, but the container app times out.

Key areas to verify in the Container Apps environment/network:

DNS and name resolution
- If the game server is reached by hostname, ensure the DNS path from the Container Apps environment is correct.
- If using a custom DNS server on the VNet, configure it to forward unresolved queries to 168.63.129.16 and ensure NSGs/firewalls allow traffic to that IP.
NSG / firewall rules on the VNet or upstream devices
- Confirm there is no rule selectively blocking UDP responses from the specific game server IP/port while allowing others.
- Ensure outbound UDP from the Container Apps subnet to the game server’s IP/port is allowed, and return traffic is not blocked.
Egress IP and remote-side filtering
- The game server sees the Container Apps environment’s egress IP, not the container’s internal IP.
- If the game server or an intermediate firewall has IP-based allow/deny rules, verify that the Container Apps egress IP is allowed for UDP on the query port.
Network contention or throughput constraints
- Container Apps environments share a single ingress/egress IP and underlying network resources. Under high load, contention or throttling could affect some UDP flows.
- If there is heavy concurrent UDP traffic to many servers, consider whether packet loss or buffer issues on either side could affect specific paths.

If the same game server works from a local machine but not from Container Apps, the most likely causes are:

DNS or NSG/firewall configuration differences in the Container Apps network path.
Remote-side filtering based on the Container Apps egress IP.

Verifying DNS forwarding to 168.63.129.16 and checking NSG/firewall rules on the Container Apps subnet and any custom DNS server is the primary recommended next step.

References:

Share via

Can Azure Container Apps receive UDP packets?

2 answers

Your answer